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Executive  Summary 

This  report  presents  the  results  of  the  Digital  Collective  Training  Study,  which  identifies 
requirements  for  the  Advanced  Distributed  Simulation  Technology  II  (ADST II)  Program  in 
support  of  evolving  digital  battlestaff  training  needs  These  requirements  are  derived  from  a 
Digital  Collective  Training  (DCT)  approach,  which  leverages  fielded  and  emerging  digital 
systems  to  provide  a  modular,  low  cost,  low  risk  DCT  course  of  action.  The  intent  of  DCT  is 
to  allow  parallel  development  of  C4I  systems,  training  and  doctrine  and  distributed 
simulation  systems  that  result  in  a  flexible  and  tailorable  training  tool.  An  implementation 
plan  for  a  Digital  Battlestaff  Sustainment  Trainer  (DBST)  driver  based  on  a  federation  of 
CCTT  SAF  and  OTB  SAF  is  proposed  for  train  up  and  execution  of  the  Division  Capstone 
Exercise  (DCX)  at  Fort  Hood,  Texas.  This  implementation  plan  includes  a  blueprint,  support 
environment,  initial  capability,  and  a  simulation  support  concept  which  best  support  digital 
staff  training  for  DCX.  Critical  DBST  functionality  required  to  support  DCX  includes  1) 
incorporation  of  a  confederation  of  CCTT  SAF  and  ModSAF/OneSAF  Testbed  as  a  ground 
maneuver  driver  in  a  Digital  Battlestaff  Sustainment  Trainer  (DBST)  for  DCX  train  up  from 
November  1999  through  March  2001  and  2)  use  of  a  confederated  CCTT  SAF  and  ModSAF 
5.0/OneSAF  Testbed  maneuver  model  as  a  Low  Overhead  Driver  for  a  Staff  COFT  in  the 
CCTT  TOC  facility  during  DCX  in  March  2001 . 

The  recommended  approach  is  the  development  of  a  federation  of  CCTT  SAF  and  OTB 
utilizing  a  bridge  for  communications.  This  federation  would  make  use  of  a  geographic 
partitioning  approach  for  supporting  DBST  exercises  that  would  provide  the  validated 
behaviors  of  CCTT  with  the  wide  variety  of  systems  and  behaviors  provided  by  OTB. 
Scalability  and  interoperability  of  the  SAFs  are  the  key  areas  that  must  be  addresses  in  order 
to  insure  success. 
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1.  Introduction 

1.1  Purpose 

The  purpose  of  this  report  is  to  present  the  results  of  the  Digital  Collective  Training  Study, 
which  identifies  requirements  for  the  Advanced  Distributed  Simulation  Technology  II 
(ADST II)  Program  in  support  of  evolving  digital  battlestaff  training  needs'.  These 
requirements  are  derived  using  a  Digital  Collective  Training  (DCT)  approach,  which 
leverages  fielded  and  emerging  digital  systems  to  provide  a  modular,  low  cost,  low  risk  DCT 
course  of  action.  This  report  includes  a  blueprint,  support  environment,  initial  capability,  and 
a  simulation  support  concept  which  best  support  digital  staff  training  for  DCX.  Critical 
DBST  Staff  COFT  functionality  required  to  support  DCX  includes  1)  incorporation  of  a 
confederation  of  CCTT  SAF  and  ModSAF/OneSAF  Testbed  as  a  ground  maneuver  driver  in 
a  Digital  Battlestaff  Sustainment  Trainer  (DBST)  for  DCX  train  up  from  November  1999 
through  March  2001  and  2)  use  of  a  confederated  CCTT  SAF  and  ModSAF  5.0/OneSAF 
Testbed  maneuver  model  as  a  Low  Overhead  Driver  for  a  Staff  COFT  in  the  CCTT  TOC 
facility  during  DCX  in  March  2001. 

1.2  Contract  Overview 

The  Digital  Collective  Training  Study  was  performed  as  Delivery  Order  (DO)  #0106  under 
the  Lockheed  Martin  Advanced  Distributed  Simulation  Technology  II  (ADST  II)  contract 
with  the  U.S.  Army  Simulation  Training  and  Instrumentation  Command  (STRICOM). 


2.  Digital  Battle  Staff  Training  Overview 

The  Army  is  implementing  digital  command  and  control  systems  from  platoon  level  through 
Corps  and  echelons  above  Corps.  These  new  digitized  systems  include  Situational 
Awareness  (FBCB2)  at  the  lower  tactical  level  (Battalion  and  Below),  and  the  upper  levels 
using  the  Army  Tactical  Command  and  Control  System(ATCCS).  Although  there  are  many 
live,  virtual  and  constructive  simulations  for  mission  training,  a  need  exists  to  train 
commanders  and  staff  to  perform  their  tasks  using  these  new  digital  systems,  especially  to 
train  for  collective  tasks. 

Past  and  current  digital  exercises  such  as  Synthetic  Theater  of  War  —  Army  (STOW- A)  and 
Fire  Support  Simulation  Trainer  (FSST)  have  focused  on  demonstrating  the  capability  of 
driving  C4I  systems  with  simulations.  FireSim  XXI,  developed  by  the  Depth  and 
Simultaneous  Attack  Battle  Lab,  Fort  Sill  and  fielded  by  the  NSC  and  STRICOM,  has 
demonstrated  the  possibilities  simulation  can  provide  to  the  training  community.  The  focus 
of  FIRESIM  XXI  has  been  on  developing  the  digital  messaging  for  the  Fires  Battlefield 


1  Through  out  this  document,  we  refer  to  training  system.  This  is  largely  due  to  the  principal  interaction  the  warfighters 
have  had  with  simulation  system  have  been  with  training  systems.  DCT  is  not  limited  to  training  exercises,  rather  the 
focus  in  on  staff  in  the  loop  exercises.  Be  they  for  training,  weapons  /  tactics  evaluations,  or  concept  exploration  the 
simulation  system  does  not  know  or  care. 
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Operating  System  (BOS).  DBST  proposes  to  build  upon  this  success  by  fielding  a  ground 
maneuver  driver  simulation  to  stimulate  the  Army  Tactical  Command  and  Control  (ATCCS) 
with  situational  awareness  and  messaging  from  maneuver  units. 

A  digital  staff  training  strategy  is  being  created  by  TRADOC  which  ranges  in  level  from 
individual  development  through  collective  training  with  staff  drills  and  section  training,  to 
full  CP  training.  For  Level  II  and  III  drills  and  staff  section  training,  TRADOC  is  developing 
a  Staff  Conduct  of  Fire  (Staff  COFT)/Low  Overhead  Driver  (LOD)  training  system  concept. 
The  digital  battle  staff  training  challenge  involves  designing  a  set  of  evolving  technical 
solutions  which  meet  the  requirements  of  this  battle  staff  training  strategy  and  enables 
development  of  digital  staff  tactic,  techniques  and  procedures  (TTPs)  on  still-being-fielded 
digital  hardware  and  software.  These  technical  solutions  need  to  leverage  fielded  and 
emerging  legacy-based  models,  after  action  review  (AAR)  tools,  interface  devices,  and 
confederations.  A  key  challenge  is  for  such  digital  training  systems  to  be  consistent  and 
scaleable  between  training  levels  to  ensure  training  transfer. 

This  study  validates  that  the  Digital  Collective  Training  (DCT)  approach  best  meets  digital 
battle  staff  training  needs  for  Staff  COFT/LOD  by  providing  a  realistic  integrated  digital 
training  environment  where  the  commander,  staff,  and  units  build  understanding  and 
confidence  that  the  TTP  and  tasks  they  perform  in  the  simulation  environment  actually  work 
in  the  field.  The  study  first  reviews  the  Army’s  evolving  digital  staff  training  strategy  and 
training  level  requirements.  The  DCT  concept  is  then  explained  in  terms  of  addressing  these 
training  needs.  Critical  DCT  legacy  and  evolving  components  are  introduced  and  exercise 
results  from  existing  components  are  presented.  A  course  of  action  recommendation  is  made 
for  ADST II  requirements  to  support  near-term  training  system  implementation.  A  DBST 
training  course  of  action,  including  blueprint,  support  environment,  initial  capability,  and  a 
simulation  support  concept  are  described  which  best  support  digital  staff  training  during  train 
up  and  execution  of  the  Division  Capstone  Exercise  (DCX)  at  Fort  Hood,  Texas.  Cost  is 
addressed  in  terms  of  the  integration  and  development  support  required  to  provide  varying 
levels  of  C4I  stimulation  capability  through  the  use  of  the  low  overhead  driver. 


3.  Assumptions 

3.1  General 

Building  a  system  that  will  train  every  warfighter  in  the  US  Army  for  every  possible 
contingency  is  an  intractable  problem.  However,  by  making  certain  assumptions,  setting 
bounds  and  focal  points,  a  cost  efficient  system  can  be  developed  that  will  meet  the  needs  of 
the  C4I  training  community. 

a)  The  primary  focus  will  be  on  the  interaction  of  humans  using  the  tactical  C4I  system 
as  opposed  to  simulated  representation  of  commanders  and  staffs  (Virtual  Command 
Posts). 

b)  The  schedule  will  be  driven  by  the  fielding  plans  for  the  C4I  digitization  systems. 

c)  A  division  structure  or  parts  of  a  division  structure  is  the  unit  size  of  interest.  The 


UNCLASSIFIED 


8 


ADST-II-CDRL-DCTS-9900 1 5 1 
May  17,  1999 


minimum  force  is  a  Battalion  Task  Force,  then  a  Brigade,  and  then  two  Brigades  with 
Division/Corps  slice. 

d)  Exercise  will  be  conducted  on  real  and  simulated  (geospecific)  terrain  of  Fort  Hood 
andtheNTC. 

e)  A  collective  training  strategy  to  maintain  proficiency  with  C4I  systems  will  require  a 
simulation  (cost  and  opportunity  to  train  only  in  the  field  is  not  supportable)  and  some 
fixed  infrastructure. 

f)  Existing  and  developing  simulation  systems  (Close  Combat  Tactical  Trainer  (CCTT) 
and  the  OneSAF  Testbed  Baseline2  (OTB)3)  will  support  the  exercises. 

g)  The  simulation  objective  is  to  minimize  new  systems  development  and  to  leverage  the 
ongoing  efforts.  A  stay  behind  collective  training  system  for  command  and  control  is 
desired. 

h)  The  initial  focus  will  be  on  maneuver  combat  units  followed  by  combat  support  and 
combat  service  support. 

i)  C4I  systems  will  continue  to  evolve  and  specific  point  to  point  interfaces  will  be 
required  to  send  and  receive  messages  to  the  C4I  systems. 

3.2  Government  Furnished  Resources 

Required  GFP/GFI  that  is  not  currently  part  of  the  ADST II  property  inventory  or  is  not 
currently  contained  in  the  ADST  II  Master  Library  has  not  been  positively  identified  for  this 
effort.  It  is  anticipated  that  the  ADST  II  C4I  and  SAF  Laboratories  will  be  used  for  some 
aspects  of  this  delivery  order. 

a)  In  support  of  this  effort  the  Government  will  provide  coordinating  draft  4th  Infantry 
Division  Digital  Battlestaff  Sustainment  Training  (DBST)  Requirements  and  other 
user  requirements  documents  collected  by  the  National  Simulation  Center  (NSC) 
regarding  DBST  and  Staff  COFT. 

b)  The  Government  will  provide  access  to  the  NSC  Laboratory’s  parallel  effort 
investigating  the  Battlefield  Functional  Area  (BFA)  and  SAF  functionality  of  CCTT 
SAF  and  ModSAF  5.0  (current  capabilities)  and  copies  of  all  post-assessment  reports. 

c)  The  Government  will  provide  access  to  CTSF,  NSC,  STRICOM,  and  PEO-C3S 
personnel  engaged  in  providing  current  DBST  and  Staff  COFT  prototype  solutions  at 
Fort  Hood,  Texas  for  assistance  in  performing  this  DO. 

d)  The  Government  will  provide  results  of  the  STRICOM/NSC  sponsored  SAF 
Assessment  for  DBST. 


2  OTB  is  the  system  derived  from  Modular  SemiAutomated  Forces  (ModSAF). 

3  The  Combined  Arms  Tactical  Trainer  SemiAutomated  Forces  (CATT  SAF)  and  the  OTB  are  programmed  to  merge  and 

become  OneSAF.  As  we  will  see  later  in  the  document,  this  program  is  supportive  of  an  early  fielding  of  OneSAF. 
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3.3  Other  Digital  Interface/Infrastructure  Assumptions 

a)  Existing  “middleware”  products  such  as  the  Tactical  Simulation  Interface  Unit 
(TSIU),  Protocol  Interface  Unit  (PIU),  and  the  Situational  Awareness  Tactical 
Internet  Data  Server  (SATIDS)  will  be  provided  to  translate  from  DIS  PDUs  to  the 
required  tactical  message  format.  Development  of  middleware  products  is  not  a  cost 
factor  in  this  study. 

b)  The  current  infrastructure  at  Fort  Hood  is  in  place  to  provide  connectivity  between  the 
fixed  C4I  sites  (such  as  the  CTSF)  and  the  Fort  Hood  CCTT  facility. 

c)  All  C4I  related  hardware  and  software  will  be  provided  GFE.  Installation  and 
integration  of  the  C4I  systems  is  not  a  cost  factor  in  this  study. 

4.  Digital  Staff  Training  Concepts 

4.1  Army  Digital  Learning  Strategy 

As  a  byproduct  of ‘digitization’,  the  U.S.  Army  Training  and  Doctrine  Command 
(TRADOC)  has  been  evolving  its  training  strategy  to  meet  the  challenge  of  learning  and 
sustaining  digital  skills.  That  effort  has  produced  a  Digital  Learning  Strategy  and  a  design 
approach  for  a  Digital  Division  Learning  Program.  This  strategy  and  approach  are  part  of  an 
evolutionary  process  which  incorporates  lessons  learned  and  reflects  changes  in  new 
doctrine,  technologies  and  learning  methodologies.  It  is  important  to  understand  that 
requirements  derived  from  this  training  strategy  should  be  used  as  the  basis  to  drive  near- 
term  and  long-term  digital  system  solutions  to  assist  in  training  the  commander  and 
battlestaff.  TRADOC  digital  training  concepts  are  represented  below  in  Figure  1 . 

The  right  portion  of  the  figure  represents  the  Digital  Learning  Strategy,  which  has  a  three- 
step  approach  to  individual  and  group  battlestaff  training.  The  objective  of  step  one  is  to 
become  proficient  in  the  ‘basics’.  Concerning  battle  command/staff  learning,  step  one 
involves  knowing  the  Military  Decision  Making  Process  (MDMP),  proficiency  in  the  tasks, 
conditions,  and  standards  (TCS)  of  individual  or  section/cell  tasks,  and  competency  in  basic 
unit  warfighting  doctrine.  The  objective  of  step  two  is  to  become  proficient  in  the  TCS  of 
both  the  hardware  and  software  of ‘digitization’  in  the  execution  of  a  tactical  warfighting 
scenario.  Step  two  encompasses  both  vertical  and  horizontal  Battle  Command/Staff  Training 
(BCST),  such  as  the  Central  Technical  Support  Facility  (CTSF)  effort  at  Fort  Hood  for  the 
FBCB2  Limited  User  Test  (LUT).  The  objective  of  step  three  is  distributed  learning  through 
the  use  of  training  support  packages  (TSPs)  to  develop  ‘hyper-proficient’  individuals,  teams, 
and  leaders.  Step  three  training  involves  continuous  learning  and  improvement  using 
interactive,  intense,  immersion-based  experimental  observation  and  execution.  The  left 
portion  of  Figure  1  represents  TSP  battlestaff  training  levels  being  created  by  TRADOC 
which  range  from  individual  development,  through  staff  drills  and  section  training,  to  full  CP 
training. 
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To  address  current  battlestaff  training  deficiencies,  TRADOC  is  developing  a  Staff  Conduct 
of  Fire  (Staff  COFT)/Low  Overhead  Driver  (LOD)  training  system  concept,  which  focuses 
on  TSP  Levels  II  and  III  as  well  as  on  Step  2  of  the  Digital  Learning  Strategy.  The  Staff 
COFT/LOD  methodology  uses  structured  training  modules  and  vignettes,  is  targeted  towards 
specific  Level  II/III  training  objectives  and  audiences,  and  is  not  focused  on  free-play,  force- 
on-force  simulation  as  are  higher  level  CP  exercises.  The  battalion  and  above  thrust  of  this 
effort,  which  involves  battle  command/staff  learning,  is  not  currently  well  supported  and 
therefore  is  likely  to  involve  new  systems  integration.  A  number  of  specified  and  implied 
requirements  are  derived  from  the  higher  levels/steps  of  this  digital  battlestaff  training 
strategy  and  these  are  described  below. 

4.2  Identified  Digital  Staff  Training  System  Requirements 

The  U.S.  Army’s  National  Simulation  Center  (NSC)  has  conducted  recent  assessments  to 
determine  capabilities  required  for  digital  battle  staff  trainers  at  brigade  level  and  below 
(NSC,  1999).  This  assessment  incorporated  formal  TRADOC  and  4th  Infantry  Division 
guidance  with  input  on  digital  staff  training  needs  as  viewed  by  brigade  and  below 
commanders  and  staff.  Results  from  digital  force  fielding  events,  such  as  Task  Force  XXI, 
DA  WE,  and  FBCB2  LUT  were  incorporated  as  well  as  ARI  research  reports  related  to  digital 
staff  training.  The  NSC  has  recognized  a  gap  in  digital  staff  training  and  has  designed  a 
digital  battle  staff  training  concept  to  meet  this  need.  The  concept  calls  for  two  levels  of 
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trainers  that  would  be  built  to  bridge  the  current  gap  between  collective  staff  training  and  the 
high  tempo  WFXs  and  CTC  rotations.  These  two  training  level  concepts  are  being  called 
Staff  COFT  and  Digital  Battle  Staff  Trainer  (DBST).  Conceptual  prototypes  (straw-men)  of 
the  trainers  were  constructed  to  conduct  requirements  assessment  and  these  preliminary 
requirements  are  useful  in  deriving  criteria  for  this  Staff  COFT/LOD  analysis.  Two  potential 
trainers  are  under  consideration,  the  Staff  COFT  and  the  DBST  (full-CP  trainer).  They  are 
distinctive  in  terms  of  scale  and  scope.  The  two  are  conceived  as  complementary  to  each 
other  as  each  targets  portions  (steps  or  levels)  of  progressive  digital  staff  training.  It  is 
conceivable  that  the  two  can  be  integrated  as  one  DBST.  Preliminary  system  requirements 
are  briefly  described  below,  along  with  digital  staff  training  requirements  derived  from  other 
Army  sources. 

4.2.1  Staff  COFT/LOD  Requirements  (Level  II-III  Battlestaff  Training) 

The  following  describes  the  key  capabilities  of  the  Staff  COFT/LOD  battlestaff  training 
concept. 

Site:  The  COFT  is  a  fixed  “generic”  BCT/TF  TOC.  ABCS  equipment  will  be 
installed  in  the  facility  and  communication  links  hard-wired.  The  user  is  not  required  to 
provide  any  equipment.  Supplemental  items  (laptops,  charts,  etc.)  will  be  a  user  option. 

ABCS  Stimulation:  A  simulation  driver  replicates  reality  for  the  units  as  it  feeds  the 
ABCS  suite  applicable  to  the  TOC  being  trained.  The  various  systems  light  up  and  have  a 
high  degree  of  inter-activity  (messaging  and  database  population)  needed  for  the  execution 
phase  of  staff  actions.  Capability  includes  near  or  fully  functional  MCS,  ASAS,  AFATDS, 
AMDWS  and  CSSCS.  FBCB2  input  would  be  simulated  by  the  driver  (no  FBCB2  screens 
actually  in  the  TOCs). 

Support:  The  unit  uses  from  0  to  4  personnel  to  set  up  and  observe/control. 
Contractor  support  can  range  from  4  to  6  depending  upon  the  complexity  of  the  exercise.  In 
some  cases,  the  unit  may  choose  to  operate  at  a  very  low  overhead  rate  for  such  events  as 
staff  section  drills. 

Scenario  Capability:  Multiple  scenarios  will  be  created  and  stored  with  the  Staff 
COFT.  New  scenarios  can  be  created  and  tailored  to  unit  preferences.  Terrain  database 
selection  can  vary  from  the  NTC  to  Korea,  SWA  or  local.  Missions  trained  can  vary  by  type 
and  phase.  For  example,  meeting  engagement,  attack  or  defend  with  selective  focus  on  all  or 
a  given  portion  of  the  fight.  Implied  in  the  term  “COFT”  are  certain  limitations  with  regard  to 
interaction  with  OPFOR.  The  OPFOR  play  is  non-competitive.  The  unit  can  in  advance  tailor 
or  create  the  scenario  and  regulate  the  degree  of  difficulty. 

Training  Considerations:  The  COFT  is  designed  to  train  basic  digital  staff  tasks  that 
target  building  proficiency  in  individual  and  crew-type  C4SI  skills.  The  training  is  best 
conducted  via  vignettes  that  can  be  repeated  as  desired  by  the  senior  trainer.  Duration  of  the 
training  sessions  will  probably  be  in  2  to  4  hour  increments.  The  trainer  has  a  comprehensive 
and  flexible  automated  AAR  capability  that  allows  printed  or  digital  take-home  packages. 
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4.2.2  DBST  Requirements  (Level  IV-V  Battlestaff  Training) 

The  following  describes  key  capabilities  identified  for  the  DBST  battlestaff  training  concept. 
These  requirements  are  important,  since  it  is  conceivable  that  the  two  digital  staff  training 
levels  can  be  integrated  as  one  DBST 

Site:  Unit  sets  up  TOC  portion  of  one  or  more  command  posts.  There  is  maximum 
flexibility  for  locations  (simulations  center  lot,  motor  pool,  field).  The  unit  uses  organic 
equipment  (to  include  ABCS)  and  sets  up  TOC  per  its  SOP.  Tactical  communications  are 
used  to  extent  possible  depending  on  location  and  distance  from  the  simulation  drivers. 

ABCS  Simulation:  The  simulation  driver  replicates  functionality  of  ABCS  suite  to 
the  extent  possible.  Situation  awareness  (common  operational  picture)  is  via 
simulation/stimulation  interface  to  include  replication  of  reality  for  FBCB2  feeds.  ABCS 
inter-activity  includes  normal  staff  operational  functions  (messages,  database)  in  reaction  to 
two-sided  tactical  events.  Normal  TOC  capability  is  MCS,  ASAS,  AFATDS,  AMDWS.  If 
ALOC  or  Log  Ops  is  linked,  CSSCS  can  be  stimulated  through  links  to  MCS. 

Support:  Relatively  low  overhead  is  the  norm  which  is  dependent  on  size  and  scope 
of  the  exercise.  Unit  operators  will  range  from  none  to  4.  Contractor  support  will  range  from 
4  to  10  on  average.  Ideally,  high  overhead  unit  functions  like  pucksters  will  be  eliminated. 
Unit  communications  support  for  setup  will  be  required  in  most  cases. 

Scenario  Capability:  Multiple  scenarios  on  varied  terrain  is  possible  and  can  be 
tailored  to  unit  desires.  Terrain  can  be  varied  from  NTC  to  Korea,  SWA  or  local.  The  full 
range  of  tactical  missions  can  be  accommodated  to  include  high  resolution  focus  on  specific 
phases  such  as  the  counter-reconnaissance  fight  of  a  deliberate  defense.  OPFOR  is 
competitive  and  play  is  fully  two-sided  with  OPFOR  played  by  contractor  overhead  or  unit. 
Degrees  of  difficulty,  tempo,  entry  points,  iteration  length,  repetition  can  be  tailored  to  fit  the 
unit’s  desires. 

Training  Considerations:  The  DBST  can  range  all  levels  of  staff  training  from  crawl 
to  run  (Steps  1  through  3).  It  is  best  used  in  a  progressive  format  following  basic  skill 
proficiencies  gained  in  the  CTSF  and  Staff  COFT.  This  trainer  can  be  used  for  up  to  7  days 
of  exercise,  and  is  ideally  suited  for  1  to  3  day  scenarios.  Multiple  CP  exercises  are  possible 
(brigade  TOC  with  full  or  partial  task  force  TOCs).  The  unit  requirements  will  include  pre¬ 
exercise  creation  and  tailoring  of  scenarios  setting  that  are  targeted  at  the  exercise  training 
objectives.  Automated  AAR  materials  will  be  provided  to  the  senior  trainer  and  unit 
observer/controllers. 

4.2.3  Other  Digital  Learning  Strategy  Requirements 

TRADOC  has  developed  a  Digital  Learning  Strategy  (TRADOC,  1998),  which  identifies 
Step  Two  training  programs  encompassing  vertical  and  horizontal  Battle  Command/Staff 
Training  (BCST).  Staff  COFT  training  concepts  can  be  used  for  such  Step  Two  training  and 
therefore,  TRADOC  Digital  Learning  Strategy  Step  Two  Characteristics  are  relevant  to  Staff 
COFT  capability  requirements.  TRADOC  Digital  Learning  Strategy  Step  Two 
Characteristics  include:  1)  training  on  equipment  (FBCB2  and  ABCS  as  appropriate  2) 
explicit  tactical  warfighting  exercises  with  seamless  integration  (vertical  and  horizontal)  3) 
embedded  performance  assessment  and  4)  tailorable  simulation  execution  (stand  alone  or 
networked).  NSC’s  Training  With  Simulations  (NSC,  1999)  lists  C2  requirements  for 
simulation  which  are  also  applicable  to  Staff  COFT/LOD.  These  C2  simulation  requirements 
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include  scenario  realism,  neutrality  to  decision  making  processes  and  the  ability  to  free  play 
staff  and  exercise  events.  Other  implied  requirements  issues  for  a  Staff  COFT  concept 
include  support  of  and  training  transfer  between  multiple  TSP  training  levels  and  the  level  of 
C4I/M&S  integration. 

5.  Digital  Collective  Training 

5.1  DCT  Concept  of  Operations 

Training  is  easy.  Cost  efficient  and  worthwhile  training  is  much  harder.  The  lack  of  a  family 
of  tools,  or  product  line,  that  can  suit  the  user’s  needs  as  they  progress  though  a  series  of 
exercise  make  supporting  training  complex.  Digital  skills  appear  to  deteriorate  more  rapidly 
than  analog  skills.  This  requires  a  cost  efficient  approach  to  training  that  reinforces  those 
critical  digital  skills  for  the  warfighter  to  be  successful.  For  the  sake  of  discussion,  Table  1 
presents  a  series  of  training  levels  a  user  goes  though  when  a  new  C4I  device  is  introduced 
into  an  armored  vehicle.  It  is  important  to  realize  that  if  the  user  has  not  seen  it,  it  is  a  new 
device,  regardless  of  how  long  it  has  been  in  the  inventory. 
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1. 

Familiar 

ization 

Level  1 

To  understand  the 
symbology  and 
switcholgy  of  the  device. 

Day  Room 

Scripted  message 
generator 

2. 

Focused 

Use 

Level  1  / 
Level  2 

To  use  the  device  in  a 
realistic  manner.  The 
user  only  has  to  deal 
with  this  one  device. 

Day  Room  /  Motor 
pool. 

SAF  system  to  drive  the 
device. 

3.  Task 
Loaded 
Use 

Level  3  / 
Level  4  / 
Level  5 

To  use  the  device  in  a 
task  loaded  environment. 

Simulation  Facility 

Device  mounted  in  a 
simulator  with  supporting 
SAF  and  other  simulators. 

4.  Field 
Use 

Level  4  / 
Level  5 

To  use  the  device  under 
“real”  conditions. 

Live  Range 

A  complete  field  exercise 

5. 

Proficie 

ncy 

Level  1  to 
Level  4 

Repetitive  usage  of  the 
device  to  maintain  skills 

Varies 

Depending  on  the  use 
case. 

6. 

Reinfor 

cement 

Level  1  / 
Level  2  / 
Level  3 

To  selectively  reinforce 
certain  aspects  of  the 
device 

Varies,  most  likely 
being  the  Day  Room 
and  Simulation 

Faculty 

A  library  of  scenarios  and 
events  to  generate  the 
desired  user  action. 

7. 

Evaluati 

on 

Level  1  to 
Level  5 

To  measure  the  user’s 
performance  using  the 
device 

Varies 

Logging  and  playback 
capability 

Table  1.  Purposes  of  Use 


Tasks  1  through  4  establish  a  gate  based  training  strategy.  The  user  must  achieve  a  degree  of 
proficiency  at  a  level  before  they  are  allowed  to  proceed  to  the  next  level  of  training.  It 
should  also  be  noted  that  the  cost  of  the  training  goes  up  for  the  first  four  rows  as  well.  By 
establishing  the  gate  based  training  system,  we  have  established  a  cost-effective  means  of 
delivering  the  training  to  the  user.  This  allows  the  application  of  training  dollars  to  the  most 
effective  payoff  area. 

5.2  Critical  DCT  Components  and  Exercise  Results 

While  not  a  component  in  the  traditional  sense,  the  single  most  important  part  of  the  DCT 
approach  is  the  training  strategies.  They  provide  the  foundational  support  for  a  set  of 
requirements  that  serves  as  a  basis  for  the  software  and  hardware  component  operations  and 
interactions.  At  run  time,  the  training  strategy  dictates  the  use  case  and  scenario.  These,  in 
turn,  dictate  which  software  and  hardware  components  will  be  used.  The  training  strategy 
drives  the  requirements  for  the  supporting  systems. 
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The  operational  C4I  system,  FCBC2  and  ATCCS,  are  the  principal  user  interfaces.  It  is 
though  these  devices  that  the  commanders  and  staffs  will  view  the  both  the  real  and  synthetic 
world.  As  such,  the  simulation  must  be  consistent  with  the  C4I  devices. 

The  simulation  systems  are  supporting  devices  that  provide  a  means  of  generating  the  entities 
in  the  battlespace,  digital  messaging  to  the  C4I  systems,  and  feedback  to  the  training 
audience  by  executing  the  scenario.  The  two  entity-based  simulation  systems  proposed  under 
the  DCT  concept  are  a  confederation  of  CCTT  SAF  and  the  emerging  OneSAF  Test  Bed.  The 
organization  of  these  SAFs  into  a  confederation  is  training  objective  and  scenario  dependent. 
The  OneSAF  Test  Bed  provides  a  wide  variety  of  entities  with  varying  levels  of  behavior 
maturity.  The  CCTT  SAF  provides  ground  based  maneuver  entities  with  validated  behaviors. 
These  systems  are  scheduled  to  merge  into  OneSAF  over  the  next  four  years.  A  detailed 
discussion  of  this  is  provided  in  section  6. 

An  interface  system  provides  the  connectivity  and  message  translation  capability  between  the 
simulation  and  C4I  systems.  The  interface  typically  receives  and  analyzes  simulation  traffic 
(DIS  PDUs)  to  determine  what  C4I  messages  should  be  generated  and  where  the  message 
should  be  routed.  These  interfaces  are  currently  standalone  systems  but,  with  the  creation  of 
C4I  -  simulation  standards  may  be  embedded  into  the  simulation  in  the  future.  Currently,  for 
the  upper  tactical  internet,  the  Tactical  Simulation  Interface  Unit  (TSIU)  provides  the  ability 
to  create  various  message  formats  (JVMF,  VMF,  et  al.)  from  DIS.  The  TSIU  relies  on  the  use 
of  signal  PDUs  to  create  these  messages.  These  unique  PDUs  are  typically  generated  using 
the  C4I  surrogate  or  the  Extended  Air  Defense  Simulation  (EADSIM).  The  Situational 
Awareness  Tactical  Internet  Data  Server  (SATIDS)  provides  connectivity  from  FBCB2  for 
the  lower  tactical  internet.  It  creates  VMF  messages  from  DIS  PDUs  and  provides  the 
situational  awareness  location  information  for  all  friendly  units.  For  the  DBST,  the  role  of 
FBCB2  is  dependent  on  the  unit  being  trained;  units  are  at  different  levels  of  digital 
capability,  some  having  FBCB2  some  not.  For  FBCB2  equipped  units,  FBCB2  “like” 
situational  awareness  must  be  provided  to  the  training  audience.  This  can  be  provided  with 
actual  FBCB2s  or  a  simulation.  In  either  case,  the  simulation  environment  must  be  robust 
enough  to  react  to  either  situation. 

In  order  to  minimize  the  amount  of  negative  training,  all  components  of  the  system  must 
operate  in  a  common  synthetic  natural  environment  (SNE).  This  requires  that  not  only  do  the 
simulations  share  a  common  environmental  representation  but  alsq  the  same  representation  is 
used  on  the  C4I  systems.  One  of  the  key  aspects  of  a  common  SNE  is  the  ability  of  the  unit  to 
practice  in  simulation  then  run  the  same  exercise  out  in  the  field.  In  doing  this,  they  can  see 
places  where  DCT  has  the  most  benefit  and  what  can  be  trained  only  out  in  the  field. 
Understanding  of  the  simulation  /  live  cycle  exercise  cycle  will  help  target  specific  task  and 
maximize  the  effectiveness  of  the  overall  training  package.  Furthermore,  to  allow  the 
simulation  /  live  exercise  cycle  to  be  run,  a  synthetic  representation  of  the  training  range  is 
also  required.  Currently,  such  representations  exist  for  Ft.  Hood  and  the  NTC.  As  the  system 
is  fielded  to  other  units,  the  number  and  location  of  databases  will  need  to  increase. 

The  focal  point  of  the  system  is  the  communication  between  the  systems,  some  of  which  are 
operational.  This  physical  connectivity  has  traditionally  been  achieved  by  deploying  the 
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communications  platoon  and  laying  new  wire.  The  Fixed  Tactical  Internet,  demonstrated  at 
Fort  Hood  in  November  1998  and  March  1999,  is  designed  to  put  a  stop  to  this  practice  by 
constructing  a  communications  infrastructure  that  meets  the  needs  of  the  simulation  and 
operational  communities.  By  not  having  to  reconstitute  the  infrastructure,  significant  cost 
savings  can  be  realized. 


6.  Computer  Generated  Forces  Analysis 

This  section  describes  and  examines  the  role  computer  generated  forces  may  play  in  support 
of  a  DBST  exercise.  A  confederation  of  SAF’s,  to  include  OTB,  and  CCTT  could  serve  as 
the  basis  for  simulation  support  for  DCX  train  up.  Three  cases  for  these  SAF’s  are  explored; 
(1)  OTB  as  a  standalone  system  (2)  CCTT  SAF  as  a  standalone  system  and  (3)  a  combination 
of  the  two.  The  OTB  and  CCTT  SAF  have  each  grown  from  a  different  set  of  requirements  to 
reach  their  particular  state. 

The  OTB  is  being  developed  from  the  existing  ModSAF  5.0  simulation.  ModSAF  was 
designed  specifically  as  a  modular,  data-driven  architecture  whose  characteristics  are  based 
on  years  of  lessons  learned  through  SAF  development  legacy.  The  ModSAF  architecture  was 
specifically  designed  to  provide  all  of  the  general  capabilities  needed  by  any  entity  level 
virtual  modeling  system.  The  ModSAF  architecture  was  also  designed  to  allow  the  easy 
development  and  integration  of  models  that  become  part  of  the  ModSAF  system.  The 
characteristics  of  the  architecture  are  that  it  is  a  single-process  architecture  and  a  layered 
inverted  architecture.  That  is,  lower  level  models  are  not  necessarily  invoked  though  a  top- 
down  sequence  of  procedure  calls  but  rather  register  themselves  to  be  called  based  on  the 
occurrence  of  particular  events.  To  accomplish  this  characteristic  and  its  data-driven 
programming  style,  the  ModSAF  architecture  makes  extensive  use  of  particular  C-language 
constructs,  most  specifically  function  pointers.  Although  the  ModSAF  architecture  was 
developed  with  general  characteristics  of  SAF  models  in  mind,  no  explicit  set  of  models  were 
initially  required  as  part  the  architecture  design.  A  large  and  diverse  development 
community  has  added  models  into  the  ModSAF  architecture  over  time.  These  additions 
range  from  models  developed  to  support  a  specific  experiment  at  a  US  Army  Battle  Lab,  to 
detailed  mine/countermine  models  in  support  of  the  JCOS  ACTD,  and  the  environmental  and 
dynamic  terrain  models  in  support  of  the  STOW  ACTD.  This  clearly  demonstrates  the 
accessibility  and  extensibility  of  the  ModSAF  architecture  design. 

CCTT  SAF  was  designed  specifically  to  satisfy  the  modeling  and  system  requirements  for 
the  CCTT  system.  Since  the  CCTT  SAF  design  occurred  after  the  initial  implementation  of 
ModSAF  ,  the  design  was  re-engineered  using  the  Ada  language  based  on  the  ModSAF 
architecture.  Therefore,  at  the  high  level  of  design  CCTT  SAF  and  ModSAF  are  very 
similar.  The  CCTT  SAF  architecture  was  designed  specifically  to  satisfy  only  CCTT’s 
system  requirements  and  no  more  because  of  a  very  short  schedule  requirement.  Adding  risk 
to  this  short  development  schedule  was  a  set  of  challenging  requirements  that  were  not 
satisfied  by  either  ModSAF  or  any  other  legacy  SAF  at  that  time.  These  requirements 
included  a  very  large  set  of  validated  and  verified  combat  instruction  sets  (CISs),  a  very  large 
and  densely  populated  terrain  database,  a  set  of  dynamic  environment  capabilities  (e.g., 
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destructible  buildings,  smoke,  weather  effects,  etc.),  and  very  stringent  performance 
requirements.  All  of  these  factors  along  with  CCTT  SAF’s  special  roles  within  the  CCTT 
system  caused  the  CCTT  SAF  design  to  diverge  from  the  ModSAF  baseline. 

CCTT  SAF  is  not  as  extensible  as  ModSAF  because  it  did  not  need  to  support  as  diverse  a  set 
of  developers.  CCTT  SAF’s  architecture  is  designed  as  a  multiple  process  and  multiple 
thread  architecture  where  the  dead  reckoning  functionality,  the  network  interface,  and  Plan 
View  Display  are  separate  processes  to  take  advantage  of  CCTT’s  multiprocessor  platform. 
CCTT  SAF  also  shares  a  significant  amount  of  common  code  within  the  CCTT  software 
baseline  for  scenario  initialization,  terrain  interoperability  and  system  component 
interoperability.  The  specific  areas  where  ModSAF  and  CCTT  SAF  differ  are  the  behaviors 
architecture  since  CCTT’s  design  was  driven  by  a  specific  set  of  required  CISs  rather  than  a 
requirement  to  be  a  general  behavior  model  development  environment.  Also  because  CCTT 
SAF  was  designed  as  a  robust  production  system  using  Ada,  it  takes  advantage  of  the 
language’s  strong  typing  and  encapsulation  practices. 

A  federation  consisting  of  OTB  and  CCTT  SAF  offers  the  potential  for  combining  the 
detailed  behaviors  of  CCTT  SAF,  in  particular  with  the  ground  vehicle  behaviors,  with  the 
breath  of  entities  and  open  software  environment  offered  by  OTB. 

The  selection  of  the  appropriate  case  to  support  a  DBST  exercise  is  scenario  dependent.  Each 
case  provides  unique  capabilities  that  may  be  required  to  support  an  exercise.  The  following 
is  a  discussion  of  the  current  and  planned  capabilities,  scalability,  interoperability,  DBST 
supportability,  and  planned  enhancements  for  each  case 

6.1  OneSAF  TestBed 

The  OneSAF  Testbed  is  an  outgrowth  of  the  Modular  Semiautomated  Forces  (ModSAF) 
program.  In  particular,  OTB  version  A,  to  be  release  in  May  1999,  is  built  on  top  of  ModSAF 
5.0.  ModSAF  historically  has  been  built  as  a  monolithic  application  with  all  libraries  or 
modules  statically  linked  together.  This  approach  forces  developers  to  relink  the  entire 
application  each  time  a  library  is  changed. 

Many  systems  allow  the  user  to  view  the  full  map  display  while  editing.  In  ModSAF,  the 
map  and  the  editors  are  combined  in  one  display.  Since  the  map  resizes  when  an  editor  is 
selected  in  ModSAF,  users  cannot  effectively  track  actions  in  a  scenario  during  editing 
operations.  This  has  been  voiced  as  one  of  the  main  usability  problems  associated  with 
ModSAF. 

Historically  in  ModSAF  it  has  been  difficult  to  access  data  for  Verification  &  Validation 
(V&V)  or  debugging  purposes  without  writing  custom,  usually  non-maintained  code. 
Additionally  the  interface  to  access  this  information  (the  SAF  parser)  in  ModSAF  was 
usually  oriented  toward  developers,  not  users.  Finally,  the  data  that  was  available  was  not 
aggregate  scenario  information  (e.g.,  number  of  entities  with  mobility  kills,  the  number  of 
blue  entities).  These  deficiencies  have  prevented  ModSAF  from  being  used  more  prevalently 
in  the  analysis  community. 
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One  of  the  strengths  of  the  SAF  is  its  portability  to  a  variety  of  hardware/OS  platforms.  The 
existing  SAF  runs  on  SGIs,  Suns,  PCs,  and  DEC  Alphas.  Because  the  Objective  OneSAF 
will  replace  the  CCTT  SAF  which  runs  under  IBM’s  AIX  operating  system,  the  OTB  SAF 
should  also  run  on  this  platform. 

This  interim  OneSAF  Testbed  is  expected  to  satisfy  the  following  requirements: 

•  Must  replace  ModSAF  with  no  decrease  in  existing  functionality  and  capability, 

•  Must  replace  CCTT  SAF  internally  in  the  CCTT  system  with  no  decrease  in  existing 
functionality  and  capability, 

•  Must  be  capable  of  providing  battalion  level  behavior  APIs  which  can  be  used  by  the 
three  Domains  to  further  develop  battalion  and  above  level  behaviors, 

•  Must  be  hardware  platform  independent  with  the  priority  on  existing  CCTT  SAF  and 
ModSAF  platforms, 

•  Must  provide  internal  DIS/HLA  interface  (with  respect  to  SAF  Systems  only), 

•  Ease  migration  to  a  new,  next-generation  OneSAF  Architecture,  and 

•  Must  support  the  ability  to  add  new  equipment,  units,  behaviors,  physical  models,  editors, 
and  synthetic  environment  representations. 

6.1.1  System  Description 

The  following  is  a  description  of  the  current  ModSAF  5.0  system  which  will  serve  as  the 
basis  for  OTB  version  A.  Architectural  changes  will  occur  in  OTB  as  it  brings  CCTT  SAF 
in  alignment.  These  architectural  changes  are  still  in  development  and  will  emerge  over  the 
development  of  OTB  Versions  A  and  B  culminating  with  the  release  of  OTB  1 .0  in  August 
2000.  Version  A  did  not  contain  significant  architectural  changes  from  the  ModSAF  baseline. 
Therefore,  this  discussion  will  refer  to  the  systems  interchangeably. 


Figure  2  shows  the  ModSAF/OTB  system.  ModSAF  is  composed  of  two  main  executables 
that  can  be  distributed  in  many  ways.  The  first  main  executable  is  the  SAF  Station.  SAF 
Stations  are  the  human  interface  to  the  ModSAF  system.  The  second  main  executable  is  the 
SAF  Sims.  The  SAF  Sims  provide  the  modeling  capabilities  for  the  ModSAF  entities  and 
organizations.  SAF  Sims  and  SAF  Stations  communicate  with  each  other  through  the  use  of 
the  Persistent  Object  (PO)  database.  This  is  a  distributed  database  that  uses  the  PO  Protocol 
(POP)  to  maintain  the  distributed  database.  In  addition,  ModSAF  uses  the  DIS  protocol  or 
the  SIMNET  protocol  to  communicate  synthetic  environment  physical  information.  The  PO 
database  communicates  information  between  the  models  that  is  not  represented  in  DIS  or 
SIMNET.  The  PO  provides  command  and  control  information  for  the  simulation  of 
organizations  (DIS  and  SIMNET  are  oriented  to  the  physical  world).  Additional  executables 
are  noted  below. 
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Figure  2:  ModSAF/OTB  System  Diagram 


6.1.2  Software  Architecture 

ModSAF  is  a  single-process  architecture.  It  makes  extensive  use  of  function  pointers  to 
provide  a  variety  of  capabilities  as  shown  below. 

•  Callbacks  -  Callbacks  provide  ModSAF  with  a  registration  structure  for  assigning 
handlers  for  a  variety  of  purposes. 

•  Inverted  architecture  -  ModSAF  uses  callbacks  to  invert  the  architecture.  This  provides  a 
mechanism  for  models  to  register  their  functions  for  various  purposes  such  as  ticking  and 
event  handling. 

•  Developer  defined  named  events  -  A  developer  may  create  a  symbolic  name  for  an  event, 
define  when  an  event  is  triggered,  and  support  registration  of  handlers  for  these  events. 

•  Scheduler  -  Periodic  and  one-shot  appointments  are  implemented  as  function  pointers  to 
tick  handlers. 

•  Key  technique  for  extensibility  -  ModSAF  uses  the  registration  capability  and  the 
inverted  architecture  to  minimize  affected  code  for  new  unit  or  model  additions  to  the 
system. 

ModSAF  has  callbacks  and  data  driven  techniques  as  the  basis  for  its  architecture.  This  is 
used  in  the  Graphical  User  Interface  design,  entity  configuration,  network  protocols,  and 
behavioral  combinations  (taskframes). 

6.1.3  Software  Structure 

ModSAF  is  a  flat  hierarchy  of  about  560  C  software  libraries.  Each  library  contains  (or  may 
contain)  a  makefile,  header  files,  C  source  files,  data  files,  GUI  resource  files,  and  TeXInfo 
library  documentation.  There  is  a  small  set  (about  1 0)  of  source  directories  containing  the 
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main  program.  In  addition  to  the  SAF  Sim  and  SAF  GUI,  the  following  main  programs  are 
part  of  the  ModSAF  5.0  baseline. 

•  DTSim  -  Dynamic  Terrain  Simulator:  Simulates  the  dynamic  terrain  protocol  and 
standards  for  ModSAF. 

•  DTScribe  -  Dynamic  Terrain  Scribe:  Provides  persistence,  serialization,  and  distribution 
of  dynamic  terrain  information. 

•  Logger  -  The  Logger  provides  the  capability  to  log  DIS  or  POP  PDUs  for  later  analysis 
or  broadcast. 

•  RTI  RD  -  The  RTI  Reliable  Distributor  implements  TCP/IP-based  reliable 
communications  for  the  RTI  version  s. 

•  Blaster  -  The  Blaster  provides  the  capability  to  broadcast  large  amounts  of  entity  state 
PDUs  for  network  loading  testing.  A  very  simple  movement  model  is  used  for  the 
entities.  No  cognitive  behaviors  or  response  to  detonation  events  are  in  the  current 
version  of  the  Blaster. 

•  ModStealth,  TAOS,  and  CFOR  represent  executables  that  are  not  part  of  ModSAF  but  the 
baseline  provides  interface  support  for  these  executables. 

6.1.4  Scalability 

Scalability  is  a  key  issue  for  a  SAFs  ability  to  support  a  DBST  exercise.  Scalability  is  defined 
as  how  well  a  solution  to  a  problem  will  work  when  the  size  of  the  problem  increases.  Many 
issues  can  effect  how  well  a  solution  scales.  The  value  of  a  simulation  such  as  Janus  is  in  the 
ability  to  place  a  large  number  of  entities  onto  the  battlefield.  Janus,  in  support  of  FSST 
exercises,  has  demonstrated  the  ability  to  place  in  the  vicinity  of  9999  entities  onto  a 
battlefield.  By  reducing  the  update  rate  for  the  systems  to  2  minute  intervals,  these  entities 
are  able  to  exist  in  the  battle  space  with  no  intelligence  but  an  ability  to  take  damage.  For  a 
Fires  scenario  with  little  or  no  maneuver,  this  meets  the  requirement.  However,  for  a  DBST 
level  III  -  V  exercise  focused  on  the  ground  maneuver  element,  a  more  intelligent  entity 
based  system  is  necessary  to  provide  cost  efficient  C4I  interactions  necessary  to  adequately 
train  the  commander  and  staff. 

Processor  speed  and  bandwidth  continue  to  be  the  limiting  factors  impacting  scalability  -  as 
processors  continue  to  improve  (Moore’s  Law  indicates  processor  speed  will  double  every  18 
months)  a  SAF  will  be  able  to  provide  more  entities  for  the  battlefield.  Total  capacity  and 
performance  benchmarks  are  difficult  to  provide  for  a  SAF  Capacity  and  performance  are 
functions  of  scenario  and  terrain  complexity.  ModSAF  requires  a  processor  with  a  minimum 
of  128  Mbytes  of  RAM  with  256  Mbytes  recommended  for  performance.  ModSAF 
performance  numbers  are  divided  into  two  groups.  The  first  group  is  a  stand-alone  capability 
with  no  remote  entities  or  network  interactions.  The  second  group  is  in  a  network 
environment  with  800  external  entities  (provided  by  an  external  program).  This  provides 
information  on  the  interaction  across  DIS  and  does  not  include  C2  interactions.  For  the 
stand-alone  version,  a  300  MHz  Pentium  II  supports  200  vehicle  simulations  while  a  195 
MHz  SGI  R10000  supports  112.  For  the  network  version,  the  Pentium  supports  132  entities 
while  the  SGI  supports  80. 
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ModSAF  currently  partitions  the  PO  Database  into  groups  of  8  maximum  participants  due  to 
scalability  concerns.  Each  partition  is  initialized  independently  and  does  not  share  C2 
information. 

ModSAF  user  workload  was  measured  during  certain  Ft.  Knox  D-site  experiments  to  be  on 
average  40  entities  per  operator.  There  was  a  high  variance  depending  on  the  side  or  activity 
of  the  entities.  During  the  DARPA  Synthetic  Theater  of  War  (STOW-97)  project,  ModSAF 
averaged  up  to  1 00  entities  per  operator. 

Scaling  to  large  exercises  is  possible  but  requires  managing  the  behaviors  for  entities.  To 
achieve  9000  entities  in  a  SAF  simulation  today  with  a  full  set  of  behaviors  would  require 
extensive  network  management  and  a  large  number  of  operators.  Based  on  a  requirement  of 
one  operator  per  100  entities  with  full  behaviors,  to  support  9000  entities  would  require 
upwards  of  90  operators.  This  is  cost  prohibitive  for  a  DBST  exercise  and  is  therefore 
unacceptable.  Scenario  design  coupled  with  exercise  management  of  behaviors  provides  the 
potential  to  achieve  large  numbers  of  entities. 

Recent  work  at  Fort  Knox  indicates  the  ability  to  provide  a  large  number  of  SAF  entities  for 
an  exercise  can  be  achieved  as  demonstrated  in  the  SimEx.  This  exercise  made  use  of 
ModSAF  4.0,  DIS2.03  with  approximately  2000  simulated  vehicles  total.  Workstations 
included  400Mhz  Solaris  X86,  Sun  Ultra2,  Sun  Ultral,  and  SGI  R1000  and  R4400  all  having 
256  Mb  RAM.  SAF  machines  were  in  pocket  mode  except  for  the  SGI  R4400,  and  each 
workstation  averaged  less  than  1 00  vehicles.  The  network  was  1  OBaseT,  with  machines 
plugged  directly  into  a  PowerHub7000.  The  most  significant  change  made  to  the  baseline  to 
reach  this  performance  level  was  to  reduce  the  network  traffic.  First,  all  ModSAF  radios 
except  for  the  artillery  radios  were  disabled,  and  the  Transmitter  heartbeat  was  reduced  to  60 
seconds.  Second,  no  ModSAF  vehicle  was  allowed  to  transmit  Entity_State  PDUs  more 
frequently  than  every  3  seconds.  Finally,  the  minefield  PDUs  were  modified  so  that  fewer 
mines  were  described.  Network  traffic  rate  was  -600  PDUs  per  second,  and  did  not  vary 
significantly  when  vehicles  moved.  The  construction  of  the  exercise  resulted  in  the 
controller's  ability  to  handle  considerably  more  entities  than  the  normal  1:100  ratio.  As  more 
entries  are  used  solely  for  indirect  fire  targets  ,  supporting  and  adjacent  forces,  and  ground 
clutter,  the  ration  should  continue  to  climb. 

Following  the  SimEx  several  additional  techniques  were  experimented  with  to  improve 
performance  to  reach  -5000  vehicles.  The  initial  approach  was  to  partition  the  network  so 
that  each  workstation  would  only  see  part  of  the  traffic.  This  was  difficult  to  accomplish  and 
manage.  Another  approach  involved  reducing  the  network  traffic  using  "super"  Entity_State 
PDUs,  each  describing  several  vehicles.  This  also  did  had  limited  success.  Another  approach 
involved  reducing  the  tick  rate  for  "distant"  vehicles  which  met  with  little  success.  Finally, 
each  workstation  was  partitioned  to  only  pay  attention  to  part  of  the  battlefield,  even  while 
PDUs  for  every  vehicle  were  on  the  network  resulting  in  a  dramatic  effect  on  the  network. 
ModSAF's  performance  is  affected  more  by  the  total  number  of  vehicles  it  has  on  its  list 
(vtab  vehicle  table)  than  by  the  total  amount  of  network  traffic.  For  this  approach,  here 
called  Area  of  Interest  (AOI),  the  battlefield  was  divided  into  a  grid  of  arbitrary  size. 
Whenever  a  Entity  State  or  Aggregate  State  PDU  was  about  to  be  sent,  the  vehicle  (or  unit) 
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location  was  converted  into  a  grid  x,y.  The  grid  x  &  y  were  stored  in  padding  fields  of  the 
PDU  and  it  was  then  transmitted  as  usual.  Each  ModSAF  maintained  a  grid  that  described 
where  its  local  vehicles  were.  When  each  local  vehicle  was  ticked,  that  vehicle's  grid  cell 
was  marked  as  "used".  Periodically,  cells  without  current  vehicles  were  marked  as  "unused", 
and  then  each  area  of  "used"  cells  was  extended  by  a  fixed  amount,  such  as  10km.  At  this 
point,  the  AOI  grid  shows  the  complete  area  of  interest  for  all  local  vehicles.  Then,  as  each 
incoming  Entity  State  or  Aggregate  State  PDU  is  received,  the  stored  grid  location  is 
retrieved  and  compared  with  the  AOI  grid.  (This  evaluation  is  performed  without  decoding 
the  PDU,  and  no  floats  are  involved.)  If  the  vehicle  described  by  the  PDU  is  a  "used"  AOI, 
the  PDU  is  immediately  discarded.  That  vehicle  will  not  appear  on  the  vtab  vehicle  table. 
The  result  was  surprisingly  effective.  Approximately,  4500  vehicles  were  generated  with  an 
average  of- 1200  PDUs/sec.  A  workstation  was  loaded  with  a  typical  force  of -100  vehicles. 
The  AOI  would  then  typically  turn  on  -2000  vehicles.  The  high  network  rate  wasn't  a 
problem.  If  a  vehicle  was  placed  in  a  new  area,  the  AOI  would  turn  on  vehicles  in  that  area. 
As  the  machine's  force  moved,  the  AOI  automatically  moved  along  with  it.  Even  scattering 
the  vehicles  worked,  since  each  only  saw  a  small  part  of  the  battlefield,  so  the  total  number  of 
vehicles  turned  by  the  AOI  was  relatively  small. 

This  AOI  model  assumes  that  while  there  are  lots  of  vehicles  in  the  world,  each  workstation 
only  needs  to  know  about  a  manageable  number  of  the  total.  It  requires  no  configuration,  and 
each  machine  can  define  its  own  buffer  size  (and  change  it  as  desired).  This  method  could  be 
used  for  much  larger  exercises  as  well.  A  set  of  machines  supporting  a  region  could  be 
protected  by  a  gateway,  and  since  the  examination  of  individual  PDUs  is  so  simple,  the 
gateway  shouldn't  have  much  trouble. 

The  Blaster,  as  depicted  in  Figure  2,  also  provides  the  ability  to  achieve  high  entity  counts 
for  SAF.  The  blaster  is  typically  used  to  provide  large  amounts  of  entities  for  network  testing. 
Currently  when  the  blaster  is  on,  the  entities  created  have  little  or  no  intelligence.  However, 
there  is  a  tradeoff  for  achieving  these  levels  of  entities  -  the  SAF  often  is  “dummied”  down. 
Scenario  development  plays  a  key  role,  focusing  on  the  areas  of  interest  and  modifying  the 
behaviors  of  the  entities  can  provide  a  high  entity  count  while  achieving  the  level  of  SAF 
intelligence  necessary  to  support  a  DBST  exercise. 

A  composable  behaviors  technique  also  offers  potential  to  addressing  scalability. 

Composable  behaviors  will  be  part  of  the  OTB  in  build  A  for  Rotary  Wing  Aircraft. 

Currently  Composable  Behavior  Technology  (CBT)  is  a  research  project  that  has  initially 
focused  on  aviation  behaviors  as  a  proof  of  principle.  This  technique  allows  the  operator  to 
create  complex  behaviors  from  a  set  of  primitive  behaviors.  This  will  allow  for  creation  of 
entities  outside  the  main  area  of  interest  with  a  limited  set  of  behaviors  thus  reducing 
processing  and  bandwidth  requirements. 

Scalability  in  OTB  can  be  achieved  through  these  load  management  techniques  in 
combination  with  scenario  design.  There  will  continue  to  be  tradeoffs  between  SAF 
capability  and  entity  count. 
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6.1.5  DBST  Supportability 

The  ability  for  OneSAF  Testbed  to  support  a  DBST  exercise  remains  scenario  dependent. 
Figure  3  depicts  a  conceptual  layout  of  the  connectivity  between  the  C4I  systems  and  the 
ground  simulation  driver  (OTB). 


Figure  3  OTB  DBST  Conceptual  Model 

FireSim  XXI  would  generate  the  fires  support  activity  for  the  exercise  and  provide  tactical 
messaging  to  the  AFATDS  via  the  PIU.  The  requirement  for  large  numbers  of  entities  is 
primarily  to  support  a  DIVARTY  exercise.  The  OTB  would  provide  the  ground  maneuver 
(expect  200  entities  for  a  battalion  combat  team  exercise;  800  entities  for  a  brigade  exercise) 
picture  and  could,  through  the  use  of  Area  of  Interest  techniques,  provide  the  large  numbers 
of  entities  for  the  fires  exercise.  The  TSIU  would  provide  the  ability  to  generate  tactical 
messages  as  well  as  routing  the  messages  to  their  appropriate  C4I  device.  The  TSIU  currently 
requires  specific  signal  PDUs  to  generate  C2  messages.  These  signal  PDUs  are  typically 
generated  by  EADSIM  or  the  C4I  surrogate.  OTB  currently  does  not  provide  these  signal 
PDUs  but  could  be  easily  modified.  A  data  logger  may  be  utilized  to  capture  the  simulation 
traffic  for  use  in  AAR  and  potential  use  for  a  STAFF  COFT. 

Scalability  as  it  relates  to  an  individual  exercise  will  be  driven  by  the  scenario.  For  the  DBST 
requirement  of  not  to  exceed  6  operators,  in  a  “standard”  scenario  operating  on  a  Pentium 
400Mhz  PC,  up  to  1200  entities  can  be  expected.  The  ability  of  an  operator  to  control  200 
entities  also  is  dependent  on  complexity  of  the  exercise. 

6.2  OTB  SAF Programmed  C4I  Upgrades 

The  OTB  program  will  be  developing  a  C4I  messaging  capability  initially  focused  on  the 
messaging  in  the  lower  tactical  internet.  A  new  C4I  Digital  Messaging  Interface  (DMI)  will 
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be  incorporated  into  the  OneSAF  Testbed  Baseline.  The  interface  will  provide  for  message 
processing  by  sending  and  receiving  digital  messages  at  the  appropriate  time  with  the 
appropriate  data.  The  interface  will  insulate  the  SAF  behavior  libraries  from  digital  message 
processing  completely.  The  behavior  libraries  will  register  with  the  interface  with  pertinent 
behavior  data,  and  the  interface  will  be  responsible  for  the  generation  of  messages  and  when 
to  send  them.  When  receiving  messages,  the  interface  will  notify  the  behavior  libraries  of 
significant  events  via  callbacks.  The  C4I  Interface  will  maintain  digital  message  types, 
message  formats,  and  processing  requirements  via  configuration  files  to  minimize  the  effects 
of  message  modifications  on  the  C4I  Interface  implementation. 

An  OTB  SAF  DMI  will  be  implemented  in  order  to  support  the  current  and  future 
requirements  for  C4I  and  digital  messaging.  This  core  interface  will  be  in  place  for  Build  B 
and  its  capabilities  will  be  demonstrated  in  an  interoperability  demonstration  with  the  Closed 
Combat  Tactical  Trainer  (CCTT)  SAF,  as  depicted  in  Figure  4.  The  demonstration  will 
consist  of  sending  and  receiving  (reacting  to  FBCB2  Variable  Message  Format  (VMF) 
messages. 

The  Tactical  Simulation  Interface  Unit  (TSIU)  will  be  utilized  to  process  the  OTB  SAF 
Signal  Protocol  Data  Units  (PDUs)  containing  the  VMF  messages.  The  TSIU  was  selected 
for  two  main  reasons:  1)  it  provides  two-way  communications,  and  2)  it  processes  Signal 
PDUs.  The  OTB  SAF  currently  uses  Signal  PDUs  for  radio  and  Longbow  IDM 
communications.  For  Build  B,  the  C4I  digital  message  processing  will  continue  to  utilize  the 
Signal  PDUs.  This  implementation  may  be  updated  in  future  releases. 


Figure  4  C4I  Digital  Message  Interface  Conceptual  Model 
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Figure  5  provides  a  more  detailed  view  of  the  DMI  architecture.  The  DMI  will  utilize  the 
network  communication  libraries  currently  implemented  in  the  OTB  SAF.  The  two  main 
parts  of  the  DMI  are  the  Digital  Message  Manager  (DMM)  and  the  Digital  Data  Manager 
(DDM). 


Simulation 

Network 


c4i  ccnmo<i2  gif 


Figure  5  C4I  Digital  Message  Interface  Architecture 


The  DMM  interfaces  directly  with  the  OTB  SAF  network  communications  library  in  order  to  process  incoming 
and  outgoing  digital  messages,  as  depicted  in  Figure  6.  The  DMM  utilizes  configuration  files  that  describe  the 
message  type  formats  (e.g.,  VMF),  therefore  if  a  message  format  changes  it  will  not  affect  the  DMM 
implementation.  The  DMM  maps  the  message  format  described  in  the  configuration  file  with  the  message  data 
provided  by  the  DDM. 
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Figure  6  Digital  Message  Manager  Conceptual  Model 


The  DDM,  as  depicted  in  Figure  7  interfaces  with  the  DMM  as  described  above.  The  DDM  interfaces  with  the 
behavior  libraries  by  providing  a  mechanism  for  the  libraries  to  register  their  pertinent  data  for  outgoing 
messages,  and  register  for  callbacks  for  significant  event  information  in  incoming  messages. 


Figure  7  Digital  Data  Manager  Conceptual  Model 


OTB  SAF  will  also  be  capable  of  a  behavioral  response  to  a  limited  set  of  C4I  messages. 
These  messages  are  currently  being  identified  but  will  predominantly  focus  on  FBCB2  VMF 
messages.  This  will  allow  the  SAF  to  respond  to  C4I  directions  such  as  a  call  for  fire  or  a 
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specific  FRAGO.  The  current  focus  of  the  OTB  C4I  effort  will  be  at  the  individual  entity 
messaging  predominantly  at  the  FBCB2  level.  This  will  not  directly  support  Battalion  and 
Brigade  level  DBST  training  but  could  serve  as  the  basis  for  a  bottoms  up  feed  of  situational 
awareness  and  C2  messaging. 

6.3  CCTTSAF 

CCTT  SAF  is  part  of  the  overall  CCTT  system  that  includes  the  CCTT  manned  modules  and 
additional  workstations.  Recently,  CCTT  SAF  has  been  decoupled  from  the  CCTT  system  to 
a  standalone  version.  This  version  essentially  offers  all  the  functionality  of  the  CCTT  SAF 
while  providing  the  flexibility  of  not  requiring  connectivity  with  the  manned  modules  for 
operation.  The  CCTT  Standalone  SAF  operates  on  a  Motorola  duel  processor  AIX  machine. 

6.3.1  System  Description 

Figure  8  shows  the  runtime  distribution  structure  for  CCTT.  CCTT  has  many  similarities  to 
the  ModSAF  structure. 


Figure  8:  CCTT  SAF  System  Diagram 


For  CCTT,  the  SAF  WS  and  OC  WS  are  equivalent  to  the  SAF  GUI  and  provide  the  human 
interface  for  the  SAF  operator  and  the  OC  trainee  respectively.  The  CGF  corresponds  to  the 
ModSAF  SAF  Sim.  The  CCTT  system  consists  of  other  executables  such  as  the  Manned 
Modules  (crew  cabin  simulations),  MCC  (master  control),  AAR  (after  action  review),  and  the 
DI  WS  (dismounted  infantry  trainee  station).  CCTT  uses  DIS  to  communicate  information 
about  the  synthetic  environment  (once  again  a  description  of  the  physical  characteristics  of 
that  world).  CCTT  SAF  uses  the  SAF  Entity  Object  Database  (SEOD)  as  a  distributed  object 
database  for  communication  between  the  workstations  and  the  CGF  simulators.  The  SEOD 
uses  the  CGF  Protocol  to  communicate  data  changes  and  events  for  command  and  control 
information.  One  point  of  comparison  between  the  ModSAF  diagram  and  the  CCTT  diagram 
is  that  CCTT  SAF  exists  as  a  integral  sub-component  of  a  larger  system. 
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A  CCTT  SAF  platform  is  an  IBM  or  Motorola  AIX  computer  system  and  costs 
approximately  $8K. 

CCTT  is  a  multi-process  architecture.  CCTT  SAF  makes  use  of  multi-process  threading  to 
allow  for  execution  of  models  on  the  symmetric  multi-processing  platform  used  by  CCTT. 
CCTT  was  written  in  Ada  83,  but  makes  limited  use  of  function  pointers.  These  are  used  to 
implement  a  callback  structure  similar  to  ModSAF.  This  callback  structure  is  used  to  allow 
for  registration  of  event  handlers  (predefined  events)  and  scheduler  appointments  (periodic 
and  one-shot).  The  CCTT  SAF  architecture  is  data  driven  as  well  but  not  to  the  extent  of 
ModSAF. 

6.3.2  Software  Structure 

The  CCTT  SAF  software  library  organization  mirrors  its  design  decomposition.  It  is  divided 
into  directories  and  subsystems  (a  Rational  Apex  concept).  Subsystems  contain  the  Ada 
packages  (specifications  and  bodies).  CCTT  relied  on  the  integrated  development 
environment  (IDE)  of  Apex  to  build  the  executables  and  did  not  use  makefiles.  The 
execution  environment  contains  all  the  data  files  and  GUI  User  Interface  Language  (UIL) 
files  necessary  for  the  execution  of  CCTT  SAF.  These  are  organized  along  the  system 
architectural  types  (i.e.,  the  system  applications  such  as  the  SAF  Workstation  and  the  CGF). 
In  CCTT  SAF,  there  is  no  equivalent  documentation  to  the  ModSAF  TeXInfo  files. 

6.3.3  Scalability 

CCTT  SAF  was  designed  specifically  to  support  company  lanes  in  a  battalion  size  scenario. 
The  SAF  is  not  scalable  to  large  numbers  of  entities  -  the  blaster  and  area  of  interest 
techniques  which  apply  to  OTB  are  not  possible  to  implement  within  CCTT  without  major 
rearchititecting.  A  typical  entity  count  for  CCTT  SAF  per  machine  is  120.  CCTT  SAF  can 
easily  support  a  battalion  combat  team  size  exercise  of  200  entities. 

6.3.4  DBST  Supportability 

The  ability  for  CCTT  SAF  to  support  a  DBST  exercise  remains  scenario  dependent.  CCTT 
SAF  as  a  standalone  can  support  battalion  and  brigade  level  ground  exercises.  A  bridge 
would  be  required  to  provide  network  management  and  FDDI  to  ethemet  connectivity. 
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Figure  9  CCTT  SAF  DBST  Conceptual  Model 


6.4  CCTT  Programmed  C4I  Upgrades 

The  CCTT  program  has  recently  modified  the  manned  modules  to  accept  FBCB2  hardware 
and  support  situational  awareness  and  digital  C2  messaging.  The  actual  FBCB2  hardware  has 
been  integrated  into  the  manned  modules  and  the  CCTT  SAF  has  been  modified  to  respond 
to  digital  messaging.  CCTT  SAF  has  been  modified  to  provide  Situational  Awareness 
information  and  C2  messaging  to  the  FBCB2. 
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CCTT  FBCB2  Design 


[  J  Separate  application 


Message  Addressing 


Figure  10  CCTT  FBCB2  Architecture 

FBCB2  messages  originate  from  current  CCTT  CGF  behaviors.  The  tactical  situation  is  the 
deciding  factor  determining  the  type  of  message  which  will  be  sent.  FBCB2  utilities  is  called 
when  certain  tactical  situations  are  present  that  require  a  VMF  formatted  message  being  sent. 
FBCB2  utilities  is  responsible  for  furnishing  the  appropriate  data  associated  with  each  VMF 
message.  This  new  situational  awareness  or  command  and  control  data  is  then  sent  to  the 
VMF  parser  to  be  translated  into  the  correct  format.  Concurrently,  CGF  positional  data  is 
sent  to  the  tactical  FBCB2  workstation  via  an  RS422  connection.  Once  the  VMF  parser 
receives  SA  or  C2  data,  it  uses  tactical  internet  services  to  retrieve  the  correct  message 
addresses  as  defined  by  the  current  Force  XXI  organizational  structure.  Once  the  VMF  parser 
has  the  message  addresses  from  internet  services,  it  encapsulates  the  VMF  message  and  sends 
it  to  the  simulated  INC  (internet  controller).  The  INC  is  responsible  for  routing  the  message 
to  the  appropriate  simulated  equipped  vehicle  or  manned  module. 

Phase  III,  completed  earlier  this  year,  of  this  upgrade  has  provided  a  capability  for  the  CCTT 
SAF  to  generate  the  following  messages  in  Table  2 
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Threat  Warning 

Call  for  Fire 

Situation  Report 

Message  to  Observer 

Message  to  Observer  report 

End  of  mission/Surveillance 

Spot  Report 

Obstacle  Report 

Position  report 

Table  2  Phase  III  CCTT  SAF  Messages 


Phase  IV  of  the  FBCB2  upgrade,  scheduled  for  completion  in  October  1 999  provides  the 
following  FBCB2  messaging  capability  in  the  CCTT  SAF 


Call  for  Fire 

Observer  Status 

Subsequent  Adjust 

Bridge  Report 

Check  Fire 

Logistics  Report 

On  Call  Fire  Command 

Bridge  Report 

End  of  Mission  /  Surveillance 

Observer  Notification 

Obstacle  Report 

Spot/Salute  Report 

Strike  Warning 

Threat  Warning 

Logistics  Report 

Strike  Warning 

Observer  Status 

Situation  Report 

Mine  Laying  Report 

Mine  Laying  Report 

Airborne  Fire  Mission 

Airborne  Fire  Mission 

Personnel  Status 

Personnel  Status 

Observer  Notification 

Subsequent  Adjust 

Table  3  Phase  IV  CCTT  SAF  Messages 
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6.5  CCTT/OTB  Federation 

6.5.1  System  Description 

Federating  CCTT  Standalone  with  an  OTB  SAF  could  provide  the  DBST  with  a  solution  for 
achieving  large  entities  counts  while  maintaining  the  detailed  behaviors  required  for  SAF  in  a 
DBST  exercise.  In  order  to  federate  CCTT  SAF  with  OTB,  several  issues  must  be  addressed 
including  network  communications,  DIS  standards,  broadcast  versus  multicast  schemes, 
terrain  interoperability,  and  “fair  fight”.  There  are  numerous  approaches  with  hardware  and 
software  to  solve  these  problems.  Hardware  solutions  are  often  a  one  time  expense  (example 
is  buying  a  power  hub)  that  usually  do  not  grow  with  a  solution  over  time.  Software  solutions 
typically  evolve  over  time  and  allow  the  system  to  grow. 

The  network  issues  focus  on  the  Fiber  Distributed  Data  Interface  (FDDI)  and  ethemet 
differences  as  well  as  the  broadcast  versus  multicast  issue.  CCTT  makes  use  of  a  Fiber  FDDI 
as  its  network  architecture  using  a  multicast  addressing  scheme.  OTB  uses  an  ethemet 
architecture,  typically  lObaseT,  with  a  broadcast  addressing  scheme.  Multicast  addressing 
sends  packets  to  specific  machines  on  a  network.  Broadcast,  which  is  a  subset  of  multicast, 
sends  packets  over  ethemet  that  all  machines  are  willing  to  accept.  The  advantage  of 
multicast  is  that  only  those  machines  subscribed  to  a  particular  set  of  groups  receive  the 
packets  sent  to  the  those  selected  groups  thereby,  filtering  out  the  unneeded  packets  and 
reducing  the  processing  requirements.  CCTT  SAF  can  be  placed  in  the  broadcast  mode  with 
minimal  degradation  as  the  CCTT  SAF  typically  receives  all  network  traffic.  The  CCTT 
manned  modules  may  experience  some  performance  degradation  as  manned  modules  make 
use  of  an  Area  of  Interest  scheme  and  in  the  broadcast  mode,  the  modules  receive  all  traffic. 
For  a  SAF  only  federation  in  DBST,  this  should  not  be  an  issue. 

To  enable  communications  between  CCTT  SAF  and  OTB,  a  bridge,  which  is  a  device  that 
forwards  traffic  between  network  segments  based  on  data  link  layer  information,  can  be 
developed.  The  bridge  would  support  protocol  exchanges  between  the  DIS  2.04  and  2.04R 
standards  and  would  be  hosted  on  a  system  with  both  an  ethemet  port  and  an  FDDI  port. 
Figure  1 1  depicts  the  functionality  offered  by  a  bridge.  This  Bridge  could  also  enable 
multicast  to  broadcast  as  demonstrated  by  the  use  of  the  Naval  Postgraduate  School  Dis 
Bridge  used  during  the  NSC  CCTT  SAF  ModSAF  Interoperability  Study  February  1999.  Us 
of  this  approach  will  negate  the  need  to  modify  the  multicast  scheme  within  CCTT.  The 
CCTT  side  of  the  bridge  would  have  to  subscribe  to  all  groups  to  ensure  it  receives  all  the 
packets  on  the  net.  The  Bridge  would  also  enable  terrain  interoperability  through  ground 
clamping  (to  be  discussed  in  interoperability  section). 
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Bridge  forwards  traffic  between  network  segments  based 
on  data  link  layer  information 


Bridge  hosted  on  duel  ported  system  with 
FDDI  and  ethemet  cards 


J  Software  to  be  developed 
j  Existing  Software 


Figure  1 1  CCTT  -  OTB  Bridge 


6.5.2  Scalability 

Scaling  of  the  CCTT/OTB  Federation  will  be  scenario  dependent.  The  combination  of 
behaviors  that  this  federation  can  provide  offer  a  great  potential  to  an  exercise  but  must  be 
properly  managed  during  an  exercise.  Figure  12  depicts  a  potential  grid  approach  for  a 
scenario  that  can  provide  the  entity  count  desired  for  a  large  entity  exercise  while  also 
providing  the  detailed  behaviors  needed  for  a  ground  maneuver  exercise.  The  size  of  each 
grid  would  be  scenario  dependent  but  we  would  anticipate  the  CCTT  SAF  supporting  a 
battalion  combat  team  of  approximately  200  entities  (red  and  blue)  with  potentially 
supporting  a  brigade  ground  exercise  of  800  entities.  The  center  grid  would  be  the  primary 
area  of  interest  for  the  ground  maneuver  unit  (typically  a  battalion  or  brigade  unit).  While  the 
figure  shows  the  grids  of  roughly  equal  size,  this  is  not  a  requirement  and,  in  actuality,  very 
seldom  happens.  The  scenario  will  dictate  the  location  and  composition  of  the  ground 
maneuver  force.  In  some  case  they  might  not  be  represented  at  all,  or  a  lower  fidelity 
representation  can  be  used.  If  this  is  the  case,  CCTT  SAF  need  not  be  part  of  the  exercise. 
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Figure  12  Notional  OTB/CCTT  Federation  Conceptual  Grid 


The  strength  of  the  CCTT  SAF  is  the  validated  behaviors  for  ground  maneuver  exercises. 
These  behaviors  are  focused  at  the  platoon  and  company  level.  The  grid  approach  allows  for 
the  DBST  exercise  to  take  advantage  of  these  behaviors.  OTB  SAF,  making  use  of  the  area  of 
interest  methodology,  could  provide  the  surrounding  units  and  achieve  the  large  number  of 
entities  required.  The  CCTT  SAF  would  provide  the  all  ground  interactions  for  the  maneuver 
unit  while  OTB  would  provide  the  surrounding  entities  to  support  the  fires  and  intelligence 
picture.  The  primary  obstacles  to  overcome  on  the  interactions  on  the  boundaries  of  the 
CCTT  SAF  with  the  OTB  SAF.  Interoperability  issues  between  the  SAFs  will  be  addressed 
below. 

Figure  1 3  CCTT  SAF/OTB  depicts  the  architectural  layout  for  a  battalion  combat  team 
exercise  with  a  surrounding  DIVARTY  exercise.  To  provide  a  battalion  combat  team  of 
CCTT  SAF  would  require  4  CGF  machines  and  2  workstations,  all  Motorola  AIX  duel 
processor  machines.  To  provide  the  supporting  entities  in  OTB  SAF  would  require  4  Pentium 
450  Mhz  machines  operating  with  a  blaster  or  area  of  interest  scheme.  The  bridge  would  be 
hosted  on  a  duel  FDDI  ethemet  card  Sun  Ultra  workstation  providing  the  network 
management  for  the  system. 
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Figure  13  CCTT  SAF/OTB 


6.5.3  Interoperability 

Interoperability  refers  to  the  ability  of  software  and  hardware  on  multiple  machines  from 
multiple  vendors  to  communicate.  The  primary  interoperability  issue  for  CCTT  and  OTB 
SAF  is  in  sharing  of  a  common  synthetic  natural  environment  (SNE).  The  SNE  represents  the 
passive/non-sentient  parts  of  the  simulation,  including  terrain/features,  ocean  and  weather. 
SNE  provides  services  to  support  behavioral  models  in  reasoning/planning  and  physical 
models  in  correctly  responding  to  ground  truth.  Sharing  of  a  common  SNE  is  essential  for 
issues  of  a  fair  fight  and  quality  training.  In  the  short  run,  scenario  design  can  address  the 
lack  of  a  common  SNE  by  preventing,  or  at  least  limiting,  interactions  across  simulations. 
However,  in  order  to  provide  a  robust  DBST  simulation  environment  which  allows  for 
interaction  among  entities  and  in  particular  if  the  manned  modules  are  introduced  into  the 
exercise  interoperability  must  be  addressed. 

OTB/ModSAF  makes  use  of  the  compact  terrain  database  structure  (CTDB)  which  provides 
the  user  with  a  decentralized,  open  interface  providing  a  great  deal  of  flexibility.  There  are 
numerous  terrain  database  sources  that  ModSAF  can  convert  from  including  SI 000,  EaSiest, 
and  Multigen  through  the  use  of  a  compiler.  CCTT  makes  use  of  the  model  reference  Terrain 
Database  (MrTDB)  which  is  a  much  more  structured  architecture.  CCTT  compilers  presently 
can  use  only  a  CCTT-specific  format  known  as  SIF++.  These  different  terrain  database 
formats  are  again  the  results  of  differing  program  requirements.  These  databases  differ  in 
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their  approach  to  feature  representation,  physical  features,  dynamic  terrain,  environment, 
man-made  effects,  and  SNE  reasoning. 

The  long  term  solution  to  the  terrain  interoperability  problem  between  CCTT  and  OneSAF 
Testbed  will  be  the  development  of  the  Synthetic  Environments  Data,  Representation  and 
Interchange  Specification  (SEDRIS)  program.  SEDRIS  is  a  Defense  Modeling  and 
Simulation  Office  (DMSO)  program  with  engineering  and  management  support  provided  by 
STRICOM.  The  SEDRIS  project  was  conceived  and  implemented  to  capture  and  provide  a 
complete  (terrain,  ocean,  atmosphere,  and  space)  data  model  of  the  physical  environment, 
access  methods  to  that  data  model,  and  an  associated  interchange  format. 


Databases  are  converted  from  a  specific  format  into 
a  standard  SEDRIS  format.  Individual  programs  develop 
a  SEDRIS  reader  to  accept  SEDRIS  format. 


Figure  14  SEDRIS  Conceptual  Model 

These  SEDRIS  developed  mechanisms  facilitate  interoperability  among  heterogeneous 
simulations  by  providing  complete  and  unambiguous  interchange  of  environmental  data.  The 
range  of  M&S  applications  addressed  in  the  SEDRIS  development  includes  training, 
analysis,  and  system  acquisition  and  supports  visual,  computer  generated  forces,  and  sensor 
perspectives.  Additionally,  SEDRIS  provides  a  standard  interface  for  geographic  information 
systems,  which  are  key  components  in  the  generation  of  complex  integrated  databases  for 
simulation  applications.  The  data  interchange  specification  supports  the  pre-runtime 
distribution  of  source  data,  three-dimensional  models,  and  integrated  databases  that  describe 
the  physical  environment  for  both  simulation  and  operational  use. 

Figure  14  depicts  the  SEDRIS  approach  to  creating  a  common  data  model.  The  intent  of  the 
development  is  to  create  one  standard  method  to  interchange  environmental  databases  in  a 
consistent  fashion  across  the  widest  possible  range  of  heterogeneous  simulation  systems  that 
incorporate  synthetic  environments.  The  interchange  specification  consists  of  the  interchange 
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format,  rules  for  generating  compliant  transmittals,  and  the  interface  description  to  the  data 
model  representation.  The  data  model  implementation  is  transparent  to  both  data  providers 
and  data  consumers.  An  API  efficiently  enables  M&S  systems  and  provider  conversion 
software  to  pass  data  through  the  data  model.  The  design  of  the  API  and  transmittal  files  does 
not  mandate  any  specific  hardware  platform  dependency.  Use  of  the  data  interchange  format 
frees  the  interchange  from  any  operating  system  dependencies.  Common  tools  and  software 
are  shared  and  reused,  thereby  achieving  a  reduction  in  conversion  and  interchange  costs.  Ad 
hoc  conversions  are  eliminated.  Therefore,  there  is  less  opportunity  for  the  loss  of  significant 
data  leading  to  correlation  problems. 

Development  of  the  conversion  programs  to  go  from  a  specific  format  to  a  SEDRIS  format  is 
on-going.  TASC  is  currently  developing  a  CTDB  to  SEDRIS  compiler.  Work  on  this 
program  continues  with  anticipated  releases  coming  in  late  1999.  SAIC  is  developing  a 
CCTT  to  SEDRIS  compiler  with  an  anticipated  delivery  of  1  January  2000.  These  programs 
should  enable  the  use  of  PI  (NTC)  and  P2  (Europe)  databases.  The  OTB  is  developing  a 
OneSAF  front-end  SEDRIS  reader  that  will  read  in  databases  formatted  in  SEDRIS  to  be 
used  with  the  OneSAF  Testbed  Baseline.  This  is  being  planned  as  a  technology  insertion  for 
build  B  but  may  be  delayed.  For  long  term  DBST  interoperability  issues,  SEDRIS  should  be 
considered  as  the  solution. 

For  the  short  term,  ground  clamping  can  be  used  to  solve  terrain  correlation  problems. 
Ground  clamping  forces  the  entity,  regardless  of  the  elevation  contained  in  the  packet,  to  be 
located  on  the  terrain  surface.  In  doing  so,  ground  clamping  provides  for  a  means  of 
conversion  between  the  CCTT  and  OTB  coordinate  systems.  This  method  has  been  used  in 
previous  interoperability  studies.  The  CCTT  modules  use  geocentric  coordinates  to  determine 
their  positions  in  the  database  independent  of  the  terrain.  ModSAF  also  uses  geocentric 
coordinates  for  vehicle  positioning  which  resulted  in  a  correlation  difference  between  CCTT 
manned  modules  and  the  ModSAF  entities.  The  error  in  the  X  and  Y  axes  are  typically  less 
than  1  meter  and  the  error  in  the  Z  axis  was  less  than  3  meters.  The  Z  axis  error  is  greater  due 
to  the  geocentric  to  MGRS  coordinate  transformations  being  done  by  ModSAF  and/or  CCTT. 
Failure  to  correct  these  errors  can  result  in  “flying  tanks”  and  other  anomalies.  By  forcing  the 
entities  to  follow  the  surface  of  the  local  terrain  skin,  the  errors  introduced  by  the  differing 
coordinate  transformations  and  database  representations  can  be  eliminated.  Ground  clamping 
would  be  provided  in  the  bridge  program  in  Figure  1 1 

6.5.4  DBST  Supportability 

Figure  1 5  depicts  the  architecture  for  a  federation  of  CCTT  SAF  with  OTB  to  support  a 
DBST  ground  maneuver  and  fires  exercise.  This  federation  offers  the  detail  of  validated 
CCTT  behaviors  for  ground  maneuver  and,  utilizing  the  grid  approach  for  scenario  laydown, 
the  potential  to  provide  large  numbers  of  entities  for  the  fires  exercise  exists.  It  also  offers  the 
potential  for  manned  CCTT  modules  to  participate  in  a  DBST  exercise. 

Development  of  the  bridge  will  be  one  key  to  providing  interoperability  between  the  SAFs. 
The  bridge  will  unite  the  FDDI  with  ethemet,  address  the  ground  clamping  issue,  and  provide 
mapping  between  DIS  2.04  and  DIS  2.04R  PDUs. 
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The  TSIU  will  provide  the  generation  of  tactical  messages  for  the  MCS,  ASAS,  AMDWS, 
and  CSSCS  while  the  PIU  will  continue  to  provide  the  messaging  for  AFATDS. 


Figure  15  DBST  Architecture 

This  federation  could  be  easily  configured  for  supporting  a  wide  variety  of  training  exercises 
ranging  from  a  battalion  through  brigade.  The  numbers  of  operators  would  be  training  event 
dependent  but  a  good  planning  figure  would  be  two  CCTT  operators  per  battalion  and  two  to 
four  operators  for  the  surrounding  OTB.  More  complex  exercises  may  require  an  increase  in 
the  number  of  operators. 

6.6  Computer  Generated  Forces  Summary 

Table  4  provides  a  summary  of  the  OTB,  CCTT  SAF,  and  federation  of  CCTT  SAF  and 
OTB.  Each  SAF  can  provide  a  the  DBST  with  an  entity  based  simulation  capability.  The 
selection  of  the  appropriate  SAF  for  a  DBST  training  event  will  be  scenario  dependent. 

OTB,  modified  to  scale  up  for  large  exercises,  could  support  a  Fires  scenario.  CCTT  SAF, 
on  its  own,  could  provide  the  ground  maneuver  driver  for  a  battalion  or  brigade  level 
exercise.  A  federation  of  OTB  with  CCTT  SAF  offers  the  potential  to  provide  the  large 
numbers  of  entities  required  of  a  Division  Fires  scenario  while  providing  the  detailed 
behaviors  to  support  a  ground  maneuver  exercise. 
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OTB 

CCTT  SAF 

Federation  of 
CCTT  SAF/OTB 

System  Requirements 

Operates  on  DEC 

Alpha,  SGI,  SUN,  PC. 
Recommend  Pentium 

450  PC  for  DBST 

LOD.  Ethernet  network 

Operates  on  IBM  or 
Motorola  AIX  machine. 
Requires  a  CGF  and  SAF 
workstation.  FDDI 
network. 

Requires  a  Bridge  to 
address  interoperability 
issues.  Bridge  could  be 
on  a  PC  with  FDDI  and 
ethemet  cards 

Scalability 

Potential  exists  to  scale 
to  large  exercises  using 
network  management 
tools  and  reduction  of 
behaviors  outside  Area 
of  Interest. 

Designed  to  support 
company  lanes  for 
Battalion  Exercises.  Can 
provide  up  to  Bde  of 
ground  entities  (blue  and 
red) 

Grid  approach  for 
federation  offers  large 
entity  count  from  OTB 
with  validated  ground 
behaviors  of  CCTT. 

Standards 

DIS  2.04 

DIS  2.04R 

Requires  a  bridge 

SNE/Interoperability 

Uses  CTDB. 

SEDR1S  conversion 
programs  in 
development 

Uses  MrTDB 

SEDRIS  conversion 
programs  in  development 

Ground  Clamping  for 
initial  terrain 
interoperability.  SEDRIS 
provides  long  term 
solution 

Behaviors 

Variety  of  behaviors  - 
generally  validated  by 
developer  for  limited 
use.  Recent 
improvements  in 

Aviation  Behaviors 

Validated  Ground 
Maneuver  Behaviors 

Potential  exists  for 
validated  CCTT 
behaviors  with  breath  of 
OTB  behaviors 

C4I  Messaging  Capability 

Programmed  for 

FBCB2  VMF  messages 
for  OTB  Build  B 

Supports  FBCB2  VMF 
messages 

FBCB2  Messaging 

Table  4  Computer  Generated  Forces  Capabilities 


7.  DBST  SAF  Implementation  Approach 

7.1  Blueprint/Implementation  Plan 

Recognizing  that  this  is  a  very  aggressive  program,  a  schedule  that  attempts  to  balance  the 
needs  to  show  progress  vs.  the  need  to  do  work  is  contained  in  Table  5.  Of  particular  interest 
is  the  conduct  of  three  developer  tests  on  one  user  exercise  within  the  first  year.  While  very 
demanding,  this  type  of  schedule  is  required  to  show  progress  and  maintain  buy  in  from  the 
larger  community.  After  the  first  Simulation  Exercise  (SIMEX),  the  developers  are  give  the 
opportunity  to  conduct  a  more  rigorous  development  cycle  building  what  we  expect  to  build 
a  fielded  product. 
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Event 

Date 

Comment 

Digital  Capstone  Exercise 

April  01(NTC) 

Notional  Exit  Criteria 

(DCX) 

September  01  (FT  Hood) 

System  Baseline  and  Code 
Freeze 

December  00 

SIMEX2 

September  00 

Full  up.  On  Site  Test 

SIMEX1  (Beta  Test) 

December  99 

On-Site  Test 

Scalability  Test 

September  99 

Network  /  System  loading 

Terrain  Test  (Alpha  Test) 

August  99 

All  on  same  perceived  terrain 

Connectivity  Test 

July  99 

All  systems  talking  to  each 
other 

Table  5.  Notional  Schedule 


While  this  schedule  shows  a  road  map  to  the  planned  DCX,  there  is  nothing  that  prevents  the 
system  being  used  in  other  experimental  programs  such  as  STRIKE  FORCE.  All  that  will  be 
required  is  a  harmonization  and  prioritization  of  the  schedules  and  requirements. 

7.2  SAF  Capabilities  for  DBST 

The  following  details  a  plan  for  implementing  a  federation  of  CCTT  SAF  and  OTB  into  the 
DBST.  Near  term  focuses  on  the  next  6  to  12  months;  mid  term  from  18  to  24  months  and 
long  term  after  24  months. 

7.2.1  Near  Term  Capability 

The  initial  DBST  capability  would  focus  on  federating  CCTT  Standalone  SAF  with  OTB 
version  A  focusing  on  the  ability  to  provide  a  large  entity  count  to  support  the  Fires  scenario 
and  provide  the  ground  maneuver  driver  for  a  brigade  exercise.  This  capability  would  allow 
the  brigade  staff  to  conduct  a  minimal  level  III-IV  DBST  exercise.  It  is  anticipated  that  this 
capability  would  be  developed  over  a  6  to  12  month  period.  The  following  plan  provides  an 
approach  for  achieving  this  capability; 

•  Bridge  -  development  of  the  CCTT  SAF  -  OTB  bridge  to  provide  network 
management  between  FDDI  and  ethemet;  translation  between  DIS  2.04  and 
2.04R;  and  ground  clamping  for  limited  terrain  operability. 

•  Scalability  test  -  develop  Area  of  Interest/Blaster  capability  for  OTB  to  provide 
6000  -  9000  entities  with  varying  levels  of  behaviors  to  support  a  Fires  exercise. 

•  Simulation  Systems  -  integration  and  test  of  CCTT  SAF  -  OTB  federation  with 
FIRESIM  XXI  and  EADSIM/C4I  surrogate. 

•  C4I  Systems  Integration  -  test  and  integration  with  the  TSIU  and  ATCCS  for 
connectivity,  message  creation,  and  message  routing. 

•  DBST  System  -  final  test  and  evaluation  of  simulation  and  C4I  systems  for 
selected  scenario. 
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Figure  16  Near  Term  Development  Schedule 
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7.2.2  Mid  Term  Capability 

The  Mid  Term  will  focus  on  addressing  the  common  SNE  for  OTB  and  CCTT  SAF  as  well 
as  development  of  behaviors  to  support  C2  messaging  for  SAF  to  facilitate  brigade  and 
battalion  operations.  Composable  behaviors  will  be  developed  to  address  the  scalability 
issues.  It  is  anticipated  that  this  would  be  developed  over  a  12  to  24  month  period.  The 
following  plan  provides  an  approach  for  achieving  this  capability; 

•  SEDRIS  Database  -  testing  of  SEDRIS  databases  in  support  of  DBST  exercises. 
This  will  eliminate  the  need  for  ground  clamping. 

•  Development  of  lower  and  upper  tactical  internet  messaging  and  behavior 
responses  in  SAF 

•  Intelligent  Interest  Management  for  bridge-  develop  and  test  improved  network 
management  to  enable  scalability. 

•  Manned  Modules  -  introduce  the  CCTT  manned  modules  into  the  federation  and 
the  DBST  training  environment. 

•  HLA  -  migrate  the  federation  towards  HLA  to  achieve  the  management  offered 
by  developing  RTIs  to  enable  participation  in  larger  federations. 
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Figure  17  Mid  Term  Development  Schedule 
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7.2.3  Long  Term  Capability 

The  long  term  will  focus  on  addressing  increased  behavior  fidelity  for  cognitive  and  physical 
models  in  support  of  command  and  control.  Increased  automation  of  SAF  behaviors  to 
develop  a  near  systemic  SAF  which  would  require  one  to  two  operators  to  conduct  a  brigade 
level  exercise.  It  is  anticipated  that  this  would  be  developed  over  a  24  to  36  month  period. 

The  following  plan  provides  an  approach  for  achieving  this  capability; 

•  Behavior  models  -  increased  composable  behaviors  for  collective  C2  messaging 
focusing  on  cognitive  and  physical  models. 

•  SAF  Automation  -  increasing  the  behaviors  for  higher  level  of  commands  to 
facilitate  a  near  systemic  SAF. 

•  C2  Messaging  -  direct  messaging  capability  from  the  SAF  to  the  C4I  system 
without  the  use  of  middleware. 

•  Digital/Non  Digital  System  Emulation  -  Support  training  for  modernized  and 
non-modemized  staff  training  systems. 

7.3  Relationship  to  OneSAF 

As  discussed  above,  the  development  of  the  SAF  confederation  between  CCTT  and  OTB  will 
provide  the  user  the  ability  to  select  between  the  best  of  both  the  systems.  This  allows  the 
testing  of  the  concepts  of  selective  fidelity  and  composable  behaviors.  Furthermore,  the  use 
of  the  SAF  confederation  in  large  scale  DBST  exercises  provides  key  insights  into  the 
requirements  OneSAF  will  have  to  meet  to  train  the  digital  Army.  As  such,  this  program 
supports  the  OneSAF  program  by  providing  both  technical  risk  reduction  and  requirements 
definition. 

8.  Cost  Estimates 

Budgetary  cost  estimates  are  provided  in  the  accompanying  cover  letter  for  the  near  and  mid 
term  capabilities.  These  estimates  are  based  on  a  rough  order  of  magnitude  evaluation  of  the 
DBST  Ground  maneuver  driver  needs.  A  full,  detailed  cost  proposal  can  be  developed  upon 
acceptance  of  the  technical  approach  and  a  detailed  requirements  document. 

9.  Conclusion 

In  summary,  the  critical  question  is  “Why  use  the  DCT  Approach?  ’ 

a)  Maximum  reuse  of  existing  components 

•  The  building  blocks  are  currently  being  fielded  to  operational  sites. 
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•  The  same  components  can  be  connected  in  a  range  of  configurations  to  meet  a  spectrum  of 
use  cases. 

a)  Components  are  at  the  start  of  their  lifecycle 

•  CCTT  and  OTB  are  evolving  into  OneSAF.  This  helps  to  speed  the  merging  process. 

•  The  cost  of  any  new  development  will  be  amortized  over  OneSAF’s  lifecycle. 

a)  Stepwise  Development 

•  Products  will  be  produced  and  shown  along  the  entire  developmental  path. 

•  By  building  up  from  known  systems,  we  can  find  problems  up  front  and  correct  them  with 
minimal  impact. 

a)  Minimum  artificiality 

•  C2  Systems  fed  at  the  same  level  as  the  real  world,  the  entity  level,  using  standard 
interfaces  and  with  the  participants  operating  in  spectrum  of  use  cases  from  a 
familiarization  mode  to  a  fully  task  loaded  environment. 

a)  Flexible  leave  behind  for  collective  training 

•  This  is  not  a  single  point  solution  hacked  together  for  a  demonstration. 

•  Linking  the  C2  systems  to  the  SAF  and  Simulators  is  a  capability  that  can  be  reconstituted 
readily  in  different  configurations. 

The  bottom  line  is  that  the  DCT  approach  provides  the  Army  with  a  product  line  simulation 
capability  that  satisfies  spectrum  of  the  short  term  needs  and  will  evolve  to  support  the 
emerging  long-term  needs. 
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11.  Acronym  List 


AAR 

After  Action  Review 

ABCS 

Army  Battle  Command  System 

ACR 

Advanced  Concepts  and  Requirements 

ACTD 

Advanced  Concept  Technical  Demonstration 

AFATDS 

Advanced  Field  Artillery  Tactical  Interface  Data  System 

AOI 

Area  Of  Interest 

API 

Applications  Programmer  Interface 

ASAS 

All  Source  Analysis  System 

ATCCS 

Army  Tactical  Command  and  Control  System 

BBS 

Brigade  and  Battalion  Simulation 

BCST 

Battle  Command/Staff  Trainer 

BDA 

Battle  Damage  Assessment 

BEWSS 

Battlefield  Environment  Weapon  System  Simulation 

BLUFOR 

Blue  Force 

C2 

Command  and  Control 

CAS 

Close  Air  Support 

CCTT 

Close  Combat  Tactical  Trainer 

CFOR 

Command  Forces 

CFS 

Command  From  Simulator 

CGF 

Computer  Generated  Forces 

CIS 

Combat  Instruction  Set 

CP 

Command  Post 

COFT 

Conduct  of  Fire  Trainer 

CTDB 

Compact  Terrain  Database 

DAR 

Data  Analysis  Report 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DBST 

Digital  Battlestaff  Sustainment  Trainer 

DCT 

Digital  Collective  Training 

DCX 

Division  Capstone  Exercise 

DDM 

Digital  Data  Manager 

DFSST 

Division  Fire  Support  Simulation  Trainer 

DI 

Dismounted  Infantry 

DI  WS 

Dismounted  Infantry  Workstation 

DIS 

Distributed  Interactive  Simulation 

DMI 

Digital  Messaging  Interface 

DMSO 

Defense  Modeling  and  Simulation  Office 

DoD 

Department  of  Defense 

DRA 

Dead  Reckoning  Algorithm 
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DRC 

Daily  Readiness  Check 

DT 

Dynamic  Terrain 

DTO 

Dynamic  Terrain  Objects 

DVW 

Dynamic  Virtual  World 

EADSIM 

Extended  Air  Defense  Simulation 

ECN 

Engineering  Change  Notice 

EM 

Environment  Model 

EmTDB 

Environment  Model’s  Terrain  Database 

FDDI 

Fiber  Distributed  Data  Interface 

FM 

Field  Manual 

FRAGO 

Fragmentary  Order 

GUI 

Graphical  User  Interface 

HLA 

High  Level  Architecture 

ICT 

Integrated  Concept  Team 

IDE 

Integration  Development  Environment 

IDT 

Integrated  Development  Team 

IP 

Internet  Protocol 

IV&V 

Independent  Verification  and  Validation 

JCM 

Joint  Countermine 

JCOS 

Joint  Countermine  Operations 

JTS 

Joint  Tactical  Simulation 

JVMF 

Joint  Variable  Message  Format 

LOD 

Low  Overhead  Driver 

LOS 

Line  Of  Sight 

LUT 

Limited  User  Test 

M&S 

Modeling  and  Simulation 

MCC 

Master  Control  Console 

MCS 

Maneuver  Control  System 

MGRS 

Milgrid 

MHz 

megahertz 

MM 

Manned  Module 

MMCM 

Magnetic  Mine  Counter  Measure 

ModSAF 

Modular  Semi-Automated  Forces 

MrsTDB 

Multi-level  Routing  Support  Terrain  Database 

MrTDB 

Model  Reference  Terrain  Database 

MTBF 

Mean  Time  Before  Failure 

NFS 

Network  File  System 

NSC 

National  Simulation  Center 

NTC 

National  Training  Center 

NTP 

Network  Time  Protocol 

OC 

Operations  Center 

OC  WS 

Operations  Center  Work  Station 

OPFOR 

Opposing  Force 

ORD 

Operational  Requirements  Document 

OTB 

OneSAF  Testbed 
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PDU 

Protocol  Data  Unit 

POP 

Persistent  Object  Protocol 

PVD 

Plan  View  Display 

R&D 

Research  and  Development 

RAM 

Random  Access  Memory 

RTI 

Runtime  Infrastructure 

SAF 

Semi-Automated  Forces 

SAF  WS 

Semi-Automated  Forces  Work  Station 

SATIDS 

Situational  Awareness  Tactical  Internet  Data  Server 

SEDRIS 

Synthetic  Environments  Data,  Representation  and  Interchange 
Specification 

SEOD 

Semi-Automated  Forces  Entity  Object  Database 

SIF 

Standard  Interchange  Format 

SLOC 

Statement  Lines  Of  Code 

SME 

Subject  Matter  Expert 

SNE 

Synthetic  Natural  Environment 

SOM 

Simulation  Object  Model 

STOW 

Synthetic  Theater  Of  War 

STRICOM 

Simulation  Training  Instrumentation  Command 

TAOS 

Total  Atmospheric  and  Ocean  Server 

TEMO 

Training,  Exercise,  Military  Operations 

TF 

Task  Force 

TO 

Task  Organization 

TOC 

Tactical  Operations  Center 

TSIU 

Tactical  Simulation  Interface  Unit 

TSP 

Training  Support  Package 

UCI 

User  Computer  Interface 

UID 

User  Interface  Data 

UIL 

User  Interface  Language 

UTM 

Universal  Transverse  Mercator 

VMF 

Variable  Message  Format 

VV&A 

Validation,  Verification  and  Accreditation 

WFX 

Warfighter  Exercise 

WS 

Work  Station 
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